Основные этапы разработки баз данных

Возможно выделить следующие этапы разработки баз данных:

  • проектирование;
  • программная реализация;
  • эксплуатация и заполнение.

Этап проектирования – это теоретическое построение исходной информационной модели базы данных. Он включает в себя:

  • сбор информации о предметной области, ее структуре, входных и выходных информационных потоках данных, изучение задач автоматизации, выделение и анализ объектов исходной совокупности, и определение связей между ними;
  • определение характеристик и свойств для каждого объекта в БД, которым назначаются поля (атрибуты), составляются отношения и исходные таблицы между ними, выполняется определение элементов данных, включаемых в базу данных, ограничения на значения данных и т.п.
  • назначение первичных ключей (полей) для каждого объекта и нормализация (разбиение) исходных таблиц;
  • диагностику корректности проекта, что обязан все выделенные объекты, их атрибуты и обрисовываемые процессы отображать на требуемом уровне детализации, отображать предметную область, требующую решения задачи;
  • определение логической структуры базы данных;
  • поддержки вопросов целостности и решение защиты базы данных. Под обеспечением целостности данных понимается совокупность мер, направленных на поддержание правильности данных в базе в любую секунду времени.

Этап программной реализации связан с разработкой приложений на компьютере, для чего нужно выполнить следующие действия:

  • обрисовать полученные таблицы средствами СУБД и ввести их в компьютер;
  • для пользователей информационной совокупности создать интерфейсы работы с БД, другими словами экранные формы для отображения и ввода данных, отчеты для печати сводных данных , запросы для получения данных;
  • выработать поддержания базы и порядок ведения данных в рабочем состоянии, работы конечных пользователей;
  • совершить тестирование совокупности, составить инструкции по работе с ней и научить персонал.

заполнения и Этап эксплуатации начинается с наполнения базы данных конкретными данными. Он включает в себя яркое ведение базы данных и её сопровождение.

При разработке БД для корпораций и крупных предприятий моделирование и анализ выполняется с применением особых программных средств, к примеру CASE-средств, каковые разрешают промоделировать потоки данных, функции и процессы предприятия, распознать узкие места и дать советы по действенной организации структуры и бизнес-процессов на предприятии.

Не считая построения моделей текущего анализа и состояния предприятия программные средства моделирования разрешают организовать спецификации и выстроить проект будущей совокупности, более того, возможно взят код программы для самый распространенных СУБД. Так, стадия моделирования может захватывать часть этапа и этап проектирования реализации информационной совокупности.

Концептуальное проектирование базы данных

Первая фаза процесса проектирования базы данных именуется концептуальным проектированием базы данных. Она содержится в создании абстрактной модели данных для разбираемой части объектов исследуемой совокупности. Эта модель данных создается на базе информации, записанной в спецификациях требований пользователей. Концептуальное проектирование базы данных полностью не зависит от таких подробностей ее реализации, как тип выбранной СУБД, комплект создаваемых прикладных программ, применяемые языки программирования, тип выбранной вычислительной платформы, и от любых вторых изюминок физической реализации. Созданная абстрактная модель данных есть источником информации для фазы логического проектирования базы данных.

Логическое проектирование базы данных

Вторая фаза проектирования базы данных именуется логическим проектированием базы данных. Ее цель пребывает в создании логической модели данных. Абстрактная модель данных, созданная на прошлом этапе, уточняется и преобразуется в логическую модель данных. Логическая модель данных учитывает изюминке выбранной модели организации данных в СУБД (к примеру, реляционная либо сетевая модель).

В случае, если абстрактная модель данных не зависит от любых физических качеств реализации, то логическая модель данных создается на базе выбранной модели организации данных в СУБД. В противном случае говоря, на этом этапе уже должно быть известно, какая СУБД будет употребляться — реляционная, сетевая, иерархическая либо объектно-ориентированная. Но на этом этапе игнорируются все остальные нюансы выбранной СУБД — к примеру, каждые особенности физической организации ее структур хранения данных и построения индексов.

В ходе разработки логическая модель данных всегда тестируется и проверяется на соответствие требованиям пользователей. Для проверки корректности логической модели данных употребляется способ нормализации. Нормализация гарантирует, что выведенные из существующей модели данных отношения не будут владеть избыточностью данных, талантливой привести к обновления по окончании их физической реализации. Кроме всего другого, логическая модель разрешённых должна обеспечивать помощь всех нужных пользователям транзакций.

Выстроенная логическая модель данных есть источником информации для этапа физического проектирования и снабжает разработчика физической базы данных средствами нахождения компромиссов, нужных с целью достижения поставленных целей, что крайне важно для действенного проектирования. Логическая модель данных кроме этого играется ключевую роль на этапе сопровождения и эксплуатации уже готовой совокупности. При верно организованном сопровождении поддерживаемая в актуальном состоянии модель данных разрешает совершенно верно и наглядно представить каждые вносимые в базу данных трансформации и создавать оценку их влияния на прикладные программы.

Нормализация базы данных

При проектировании баз данных самый важным есть определение связей и структур таблиц между ними. Неточности в структуре данных тяжело, а чаще по большому счету нереально исправить программным методом. Чем лучше структура данных, тем легче программировать БД. Теория проектирования БД содержит концепцию обычных форм, предназначенных для оптимизации структуры БД. Обычные формы — это линейная последовательность правил, используемых к БД, причем, чем выше номер обычной формы, тем идеальнее структура БД. Нормализация — это многоступенчатый процесс, при котором таблицы БД организуются, разъединяются и эти приводятся в порядок. Задача нормализации — устранить из БД кое-какие нежелательные характеристики. В частности, ставится задача устранить кое-какие виды избыточности данных и именно поэтому избежать аномалий при трансформации данных. Странности трансформации данных — это сложности при операциях вставки, удаления и изменения данных, появляющиеся из-за структуры БД. Не смотря на то, что существует довольно много уровней, в большинстве случаев достаточно выполнить нормализацию до Третьей обычной формы.

Разглядим пример нормализации БД управления доставкой заказов. Неупорядоченная БД «Продажи» состояла бы из одной таблицы (рис.7).

Клиент Код товара Наименование товара Количество Цена Всего
Иванов 222,333,444 Телефон, Стол, Стул 3,5,7 8,10,4 160,100,900

Рис.7. БД «Продажи»

В таблице любая запись содержит сведения о нескольких заказах одного клиента. Потому, что столбец со сведениями о товаре содержит через чур много данных, взять упорядоченную данные из данной таблицы сложно (к примеру, составить отчет о суммарных закупках по разным видам товаров).

Первая обычная форма

Первая обычная форма предопределяет атомарность всех данных, содержащихся в столбцах. Слово атом происходит от латинского atomis, что практически свидетельствует не подлежащий разделению. Первая обычная форма задает существование в каждой позиции, определяемой столбцом и строкой, лишь одного значения, а не массива либо перечня значений. Преимущества этого требования очевидны: в случае, если в одном столбце сохраняются перечни значений, то не существует несложного метода манипулировать этими значениями. Само собой разумеется, наряду с этим возрастает количество записей в таблице.

Выполним нормализацию БД Продажи до первой обычной формы (рис.8).

Клиент Код товара Наименование товара Количество Цена Всего
Иванов Телефон
Иванов Стол
Иванов Стул

Рис.8. Первая обычная форма

3.3.2. Вторая обычная форма

Ко Второй обычной форме возможно перейти от таблицы, которая уже соответствует первой обычной форме. Дополнительно должно выполняться следующее условие: каждое не главное поле должно абсолютно зависеть от первичного ключа.

Выполним нормализацию БД Продажи до второй обычной формы. Все сведения, не связанные с отдельными заказами, выделим в отдельную таблицу. В итоге возьмём вместо одной таблицы Продажи возьмём две — таблицу Заказы (рис.9) и таблицу Товары (рис.10).

Клиент Код товара Количество Всего
Иванов
Иванов
Иванов

Рис.9. Таблица Заказы

Код товара Наименование товара Цена
Телефон
Стол
Стул

Рис.10. Таблица Товары

Так, вид товара хранится лишь в одной таблице. направляться обратить внимание, что при нормализации информация не теряется.

3.3.3. Третья обычная форма

Считается, что таблица соответствует Третьей обычной форме, если она соответствует второй обычной форме и все не главные столбцы взаимно свободны. Столбец, значения которого получаются вычислением на базе данных из вторых столбцов, представляет собой один из примеров зависимости.

Выполним нормализацию БД Продажи до третьей обычной формы. Для этого направляться удалить из таблицы Заказы столбец Всего. Значения в этом столбце не зависят ни от одного ключа и смогут быть вычислены по формуле (Цена)*(Количество). Так, взята БД Продажи с оптимальной структурой, которая складывается из двух таблиц (рис.11).

Клиент Код товара Количество
Иванов
Иванов
Иванов
Код товара Наименование товара Цена
Телефон
Стол
Стул

Рис. 11. Нормализованная БД Продажи

3.2 Программная реализация базы данных

Программная реализация базы данных осуществляется при помощи создания целевой СУБД на языке определения данных (DDL). Команды DDL-языка компилируются и употребляются для схем и пустых файлов базы данных. На этом же этапе определяются и все своеобразные пользовательские представления.

Прикладные программы реализуются посредством языков третьего либо четвертого поколения. Кое-какие элементы этих прикладных программ будут воображать собой транзакции обработки базы данных, записываемые на языке манипулирования данными (DML) целевой СУБД и вызываемые из программ на базисном языке программирования — к примеру, на Visual Basic, С++, Java. Помимо этого, на этом этапе создаются другие компоненты проекта приложения — к примеру, экраны меню, формы ввода данных и отчеты. направляться учитывать, что многие существующие СУБД имеют собственные инструменты разработки, разрешающие скоро создавать приложения посредством непроцедурных языков запросов, разнообразных генераторов отчетов, генераторов форм, генераторов графических генераторов и изображений приложений.

На этом этапе кроме этого реализуются применяемые приложением средства защиты базы данных и помощи ее целостности. Одни из них описываются посредством языка DDL, а другие, быть может, потребуется выяснить иными средствами — к примеру, посредством дополнительных утилит СУБД либо при помощи создания прикладных программ, реализующих требуемые функции.

3.2.1. Разработка приложений

Разработка приложений – это проектирование прикладных программ и интерфейса пользователя, предназначенных для работы с БД. Как правило проектирование приложений нельзя завершить до окончания проектирования базы данных. Иначе, база данных предназначена для помощи приложений, а потому между фазами проектирования базы данных и проектирования приложений для данной базы данных обязан всегда происходить обмен информацией.

Нужно убедиться, что все функциональные возможности, предусмотренные в спецификациях требований пользователей, обеспечиваются интерфейсом пользователя соответствующих приложений. Это относится как к проектированию прикладных программ доступа к информации в базе данных, так и к проектированию транзакций, т.е. проектированию способов доступа к базе данных.

Кроме проектирования способов, благодаря которым пользователь сможет получить доступ к нужным ему функциональным возможностям, направляться кроме этого создать соответствующий интерфейс пользователя приложений базы данных. Данный интерфейс обязан предоставлять нужную пользователю данные самым удобным для него образом.

3.2.2 Тестирование базы данных

Тестирование — процесс исполнения прикладных программ с целью поиска неточностей. Перед тем как применять новую совокупность на практике, ее направляться шепетильно проверить. Этого возможно добиться методом разработки продуманного метода тестирования с применением настоящих данных, что должен быть выстроен так, дабы целый процесс тестирования выполнялся строго последовательно и методически верно. Задачей тестирования не есть процесс демонстрации отсутствия неточностей, оно вряд ли сможет показать отсутствие неточностей в программном обеспечении — скорее, напротив, оно способно только продемонстрировать их наличие. В случае, если тестирование совершено удачно, то непременно вскроются имеющиеся в структурах базы и прикладных программах данных неточности. В качестве побочного результата тестирование может только продемонстрировать, что база данных и прикладные программы трудятся в соответствии с их спецификациями и удовлетворяют наряду с этим существующим требованиям, предъявляемым к производительности. Помимо этого, сбор статистических данных на стадии тестирования разрешает установить качества и показатели надёжности созданного ПО.

Как и при проектировании баз данных, пользователи новой совокупности должны быть вовлечены в процесс ее тестирования. В совершенстве, тестирование совокупности должно проводиться на отдельном наборе оборудования, но обычно это легко нереально. При применении настоящих данных принципиально важно предварительно создать их резервные копии, на случай их повреждения в следствии неточностей. По завершении тестирования процесс создания прикладной совокупности считается законченным, и она возможно передана в промышленную эксплуатацию.

3.3 сопровождение и Эксплуатация базы данных

сопровождение и Эксплуатация — помощь обычного функционирования БД.

На прошлых этапах приложение базы данных было полностью реализовано и протестировано. Сейчас совокупность входит в последний этап собственного жизненного цикла, именуемый сопровождением и эксплуатацией. Он включает исполнение таких действий, как:

  • контроль производительности совокупности. В случае, если производительность падает ниже приемлемого уровня, то может потребоваться дополнительная реструкуризация базы данных;
  • модернизация и сопровождение (при необходимости) приложений баз данных. Новые требования включаются в приложение базы данных при повторном исполнении прошлых этапов жизненного цикла.

Когда база данных будет введена в эксплуатации, направляться всегда контролировать процесс ее функционирования — это разрешит убедиться, что другие показатели и производительность соответствуют предъявляемым требованиям. Обычная СУБД в большинстве случаев предоставляет разные утилиты администрирования базы данных, включая утилиты загрузки данных и контроля за функционированием совокупности. Подобные утилиты способны отслеживать работу совокупности и предоставлять данные о разных показателях, таких как уровень применения базы данных, эффективность совокупности блокировок (включая сведения о количестве прошедших обоюдных блокировок), и выбираемые стратегии исполнения запросов. Администратор базы разрешённых может использовать эти сведенья для настройки совокупности с целью увеличения ее производительности (к примеру, за счет создания дополнительных индексов), ускорения исполнения запросов, трансформации структур хранения, объединения либо разбиения отдельных таблиц.

Процесс мониторинга обязан поддерживаться в течении всего процесса эксплуатации приложений, что разрешит в любую секунду времени совершить действенную реструкуризацию базы данных с целью удовлетворения изменяющихся требований. Подобные трансформации предоставляют данные о самоё вероятном совершенствовании БД и ресурсах, каковые смогут потребоваться в будущем. В случае, если в применяемой СУБД нет некоторых нужных утилит, то администратору придется или создать их самостоятельно, или купить требуемые дополнительные инструменты у сторонних разработчиков.

4. СУБД Микрософт Access

4.1.общие сведения и Назначение о СУБД Микрософт Access

Совокупность Микрософт Access есть совокупностью управления БД, применяет реляционную модель данных и входит в состав пакета прикладных программ Микрософт Office. Она предназначена для хранения, ввода, редактирования и поиска данных, и выдачи их в эргономичном виде.

К областям применения Микрософт Access возможно отнести следующие:

  • в малом бизнесе (бухучёт, ввод заказов, ведение информации о клиентах, ведение информации о деловых контактах);
  • в больших корпорациях (приложения для рабочих групп, совокупности обработки информации);
  • в качестве персональной СУБД (справочник по адресам, ведение инвестиционного портфеля, поваренная книга, каталоги книг, пластинок, фильмов и т. п.).

Access есть одной из самых замечательных, эргономичных и несложных совокупностей управления базами данных. Потому, что Access входит в состав Микрософт Office, она владеет многими чертами, характерными для приложений Office, и может обмениваться с ними информацией. К примеру, трудясь в Access, возможно открывать и редактировать файлы, и применять буфер обмена для копирования данных из вторых приложений.

Средствами разработки объектов в Access являются «мастера» и «конструкторы». Это особые программы, каковые помогают для и редактирования таблиц, запросов, отчётов и различных типов форм. В большинстве случаев «мастер» употребляется для, а «конструктор» — для редактирования объектов. Процесс редактирования предполагает изменение вида некоего объекта с целью его улучшения. При редактировании формы возможно поменять заглавия и порядок размещения полей, расширить либо снизить размер области ввода данных, и т.д. Возможно применять «конструктор» и для форм, но это весьма трудоемкая работа. В Access включены особые программные средства, помогающие создавать анализ структуры данных, импортировать текстовые данные и электронные таблицы, повышать быстродействие приложений, создавать и настраивать приложения с применением встроенных шаблонов. Дабы абсолютно автоматизировать работу приложений, возможно применять макросы для связывания данных с отчётами и формами.

В Access реализовано управление реляционными базами данных. Совокупность поддерживает первичные и внешние ключи. Снабжает целостность данных на уровне ядра, что не разрешает несовместимые операции обновления либо удаления данных. Таблицы в Access снабжены средствами проверки допустимости данных, т.е. не разрешается некорректный ввод. Каждое поле таблицы имеет стандартные описания и свой формат, что облегчает ввод данных. Access поддерживает следующие типы полей, а также: вкладка, текстовый, числовой, счетчик, финансовый, дата/время, MEMO, логический, гиперссылка, поля объектов OLE, вложение и вычисляемый. В случае, если в полях не оказывается никаких значений, совокупность снабжает полную помощь безлюдных значений.

В Access возможно применять графические средства, как и в Микрософт Word, Excel, PowerPoint и других приложениях, разрешающие создавать разные виды диаграмм и графиков. Возможно создавать гистограммы, двухмерные и трехмерные диаграммы. В формы и отчеты Access возможно додавать всевозможные объекты: картинки, диаграммы, аудио- и клипы. Связывая эти объекты с созданной базой данных, возможно создавать отчёты и динамические формы. Кроме этого в Access возможно применять макросы, разрешающие автоматизировать исполнение некоторых задач. Они разрешают открывать и закрывать формы и отчеты, создавать меню и диалоговые окна с целью автоматизации создания разных прикладных задач.

В Access возможно взять контекстно-зависимую справку, для получения которой нужно надавить , и на экране покажется справочная информация по тому вопросу, что интересует пользователя в текущий момент. Наряду с этим возможно легко перейти к оглавлению справочной совокупности, конкретной информации, изданию прошлых обращений и закладкам. Информация базы данных хранится в файле с расширением .accdb.

4.2. Объекты Микрософт Access

При запуске СУБД Access появляется окно для новой базы данных либо для работы с ранее созданными БД, либо уже имеющимися шаблонами (рис.12).

Основные этапы разработки баз данных

Рис. 12. Запуск Access

Шаблоны являются безлюдные структуры баз данных, в которых выяснены типы полей, созданы главные объекты, осуществлена связь между таблицами и т.п.

При создании новой базы данных Access откроет пустую таблицу, содержащую одну строчок и два столбца (рис 13).

Основные этапы разработки баз данных

Рис.13. Окно новой базы данных

В левой части окна (область переходов) продемонстрированы все созданные объекты БД, пока мы только видим, пустую таблицу, т.к. созданных объектов в новой базе данных больше нет (рис. 13). К главным объектам СУБД Access относятся следующие.

Таблицы. Таблицы являются главными объектами баз данных, поскольку в них сохраняются все сведенья, и они определяют структуру базы данных. База разрешённых может содержать тысячи таблиц, размеры которых ограничиваются лишь дешёвым пространством на твёрдом диске компьютера. Количество записей в таблицах определяется количеством твёрдого диска, а количество полей не более 255.

Таблицы в Access смогут быть созданы следующим образом:

  • в режиме «конструктора»;
  • в режиме ввода данных в таблицу.

Создать таблицу возможно методом импорта данных, хранящихся в другом месте, либо создания связи с ними. Это возможно сделать, к примеру, с данными, хранящимися в файле Excel, в перечне Windows SharePoint Services, XML-файле, второй базе данных MS ACCESS. Перечень SharePoint разрешает дать доступ к данным пользователям, у которых не установлено приложение MS ACCESS. При импорте данных создается их копия в новой таблице текущей базы данных. Последующие трансформации, вносимые в данные, не будут оказывать влияние на импортированные эти, и напротив. В случае, если осуществляется связывание с данными, в текущей базе данных создается связанная таблица, снабжающая динамическое подключение к данным, хранящимся в другом месте. Трансформации данных в связанной таблице отражаются в источнике, а трансформации в источнике — в связанной таблице.

В режиме таблицы отображаются эти, каковые сохраняются в таблице, а в режиме «конструктора» отображается структура таблицы.

В случае, если таблицы имеют неспециализированные поля, возможно воспользоваться подчиненной таблицей, дабы засунуть в одну таблицу записи из второй. Таковой подход разрешает в один момент просматривать эти из нескольких таблиц.

Запросы. Запросы — это особые средства, предназначенные для анализа и поиска информации в таблицах базы данных, отвечающей определенным параметрам. Отысканные записи, именуемые результатами запроса, возможно просматривать, редактировать и разбирать разными методами. Помимо этого, результаты запроса смогут употребляться в качестве базы для вторых объектов Access. Существуют разные типы запросов, самый распространенными из которых являются запросы на выборку, параметрические и перекрестные запросы, запросы на удаление записи, изменение и другие. Реже употребляются запросы на запросы и действие SQL (Structured Query Language). В случае, если нужного запроса нет, то его возможно создать дополнительно.

Запросы формируются разными методами, к примеру, посредством «мастера», кроме этого возможно создать запрос вручную в режиме «конструктора». Несложным и чаще всего применяемым видом запросов есть запрос на выборку. Эти запросы выбирают эти из одной либо нескольких таблиц и формируют из них новую таблицу, записи в которой возможно изменять. Запросы на выборку необходимы для вычисления сумм, нахождения и средних значений вторых итоговых значений. Так, запросы применяют эти из главных таблиц и создают временные таблицы.

Формы. Формы употребляются для редактирования и ввода записей в таблицах базы данных. Формы возможно отображать в трех режимах: в режиме, предназначенном для ввода данных, в режиме таблицы, где эти представлены в табличном формате, и в режимах «конструктора» и «макета», разрешающих вносить дополнения и изменения в формы.

Главными элементами формы являются надписи, в которых указан текст, конкретно отображающийся в форме, и поля, которые содержат значения полей таблицы. Не смотря на то, что режим «конструктора» разрешает создать форму с нуля, в большинстве случаев он употребляется для совершенствования и доработки форм, созданных посредством «мастера». Кроме перечисленных выше средств формы кроме этого возможно создавать посредством следующих инструментов:

  • «форма»;
  • «поделённая форма»;
  • «пара элементов»;
  • «безлюдная форма».

Самый действенно применять формы для ввода данных в виде особых бланков, поскольку форма может иметь вид бланка. Использование форм разрешает вводить данные в эргономичном для пользователя виде привычных документов. Формы ввода-вывода разрешают вводить данные в базу, просматривать их, изменять значения полей, додавать и удалять записи. Форма может содержать кнопку, применяемую для печати отчета, открытия вторых объектов либо автоматического исполнения вторых задач.

Отчеты. Отчеты употребляются для отображения информации в таблицах в отформатированном виде, что наглядно представляется как на экране монитора, так и на бумаге. Отчет есть действенным средством для вывода данных на печать из базы данных в форме, требуемой для пользователя (в виде справок, экзаменационных ведомостей, таблиц и т.д.). Кроме данных, извлеченных из нескольких запросов и таблиц, отчеты смогут включать элементы оформления, характерные печатным документам, как, к примеру, заглавия, колонтитулы и заголовки.

Отчет возможно отобразить в четырех режимах: в режиме «конструктора», разрешающем поменять внешний вид отчета, в режиме просмотра примера, в котором возможно отобразить все элементы готового отчета, но в сокращенном виде, в режиме «макета», разрешающем более наглядно отображать (если сравнивать с режимом конструктора) и форматировать отчет, и в режиме предварительного просмотра, где отчет отображается в том виде, в каком будет напечатан.

Таблицы, запросы, формы и отчеты являются объектами , каковые самый активно применяются при разработке баз данных Access.

Но возможности базы данных возможно значительно расширить, в случае, если воспользоваться страницами доступа, модулями и макросами.

Страницы.Дабы дать пользователям Интернета доступ к информации, в базе разрешённых можно создать особые страницы доступа к данным. Посредством страниц доступа к разрешённым можно просматривать, додавать, изменять и обрабатывать эти, хранящиеся в базе данных. Страницы доступа к данным смогут кроме этого содержать эти из вторых источников, к примеру, из Excel. Для публикации информации из базы данных в Web Access включают «мастер», что снабжает создание страницы доступа.

Макросы.Макросы являются маленькие программы из одной либо более макрокоманд, делающих определенные операции, благодаря которым обеспечивается, к примеру, открытие формы, печать отчетов, щелчок кнопки и т.п. Это особенно комфортно, в случае, если предполагается передать базу данных неквалифицированным пользователям. К примеру, возможно написать макросы, которые содержат последовательность команд, делающих рутинные задачи, либо связать такие действия, как открытие формы либо печать отчета, с кнопками кнопочной формы.

Модули.Модуль — объект базы данных, что разрешает создавать функций и библиотеки подпрограмм, применяемых во всем приложении. Применяя коды модулей возможно решать такие задачи, как обработка неточностей ввода, применение и объявление переменных, организация циклов и т.п.

Базы данных, лекция №1 (2013 г.)


Интересные записи:

Понравилась статья? Поделиться с друзьями: