Главная страница
Навигация по странице:

  • «

  • Отчёт по нир

  • Отчёт по нир. Завод по производству стиральных машин


    Скачать 0.52 Mb.
    НазваниеЗавод по производству стиральных машин
    Дата03.11.2022
    Размер0.52 Mb.
    Формат файлаdocx
    Имя файлаОтчёт по нир.docx
    ТипПлан работы
    #768829

    ФЕДЕРАЛЬНОЕ ГОСУДАРСТВЕННОЕ АВТОНОМНОЕ ОБРАЗОВАТЕЛЬНОЕ УЧРЕЖДЕНИЕ

    ВЫСШЕГО ОБРАЗОВАНИЯ

    «САНКТ-ПЕТЕРБУРГСКИЙ ПОЛИТЕХНИЧЕСКИЙ УНИВЕРСИТЕТ ПЕТРА ВЕЛИКОГО»

    Институт компьютерных наук и технологий

    Высшая школа программной инженерии



    Отчёт по нир

    Студент гр. 3540202/10201 Л.Юаньчжи

    Руководитель

    Санкт-Петербург

    2022 г

    План работы


    Тема: Завод по производству стиральных машин.

    Объект: системное программирование.

    Предмет: завод по производству стиральных машин.

    План:

    Введение

    1. Проектирование базы данных

      1. Алгоритм работы программы

      2. Анализ предметной области

      3. Инфологическое проектирование

      4. ER – модель

      5. Даталогическое проектирование базы данных

    2. Физическая реализация базы данных

      1. Структура таблицы базы данных

      2. Формы базы данных библиотеки

      3. Отчеты базы данных

      4. Запросы базы данных

    Заключение

    Список литературы

    Основная часть работы


    Введение:

    Целью курсовой работы является проектирование и разработка информационной системы «Завод по производству стиральных машин».

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

    Проектирование БД завода по производству стиральных машин ведется для упрощения учета и контроля выпускаемой продукции.

    Программа должна обеспечивать выполнение следующих функций:

    • Добавление и хранение информации о моделях стиральных машин;

    • Добавление и хранение информации о цехах завода;

    • Добавление и хранение информации о выпускаемой заводом продукции;

    • Редактирование информации;

    • Составление отчетов.

    Пользовательское приложение будем создавать на языке программирования Delphi 7, предварительно спроектировав базу данных в системе управления базами данных СУБД Access 2007.

    1. Проектирование базы данных

      1. Алгоритм работы программы

    Для создания программы ее нужно предварительно сконструировать, разбить на определенные блоки и выстроить эти блоки один за другим в соответствии с заранее заданным порядком действий.

    Этот порядок и называется алгоритм.

    Алгоритм - заранее определенное, точное предписание, которое задает дискретный (пошаговый) процесс, начинающийся определенным образом и приводящий к результату за конечное число шагов. Каждый алгоритм должен обладать следующими свойствами:

    • дискретность - каждый алгоритм должен быть разбит на конечное число законченных действий;

    • результативность - каждый алгоритм направлен на решение конкретной задачи, а, следовательно, на получение определенного результата;

    • массовость - алгоритм необходимо составить так, чтобы с его помощью можно было решать подобные задачи.

    Способы записи алгоритма:

    1. формальный - запись алгоритма словесно, на естественном языке;

    2. графический - изображение алгоритма в виде блок-схемы.

    На рисунке 1 изображен алгоритм программы.



    Рисунок 1 – Алгоритм программы

      1. Анализ предметной области

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

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

    Для каждого цеха известен его руководитель и штатная численность рабочих данного цеха.

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

      1. Инфологическое проектирование

    Инфологическая модель (информационно-логическая модель) — ориентированная на человека и не зависимая от типа СУБД модель предметной области, определяющая совокупности информационных объектов, их атрибутов и отношений между объектами, динамику изменений предметной области, а также характер информационных потребностей пользователей. Инфологическая модель предметной области может быть описана моделью "сущность—связь" (моделью Чена), в основе которой лежит деление реального мира на отдельные различимые сущности, находящиеся в определенных связях друг с другом, причем обе категории — сущность и связь полагаются первичными, неопределенными понятиями.

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

    Основные понятия:

    • Сущность – любой различимый объект (объект, который мы можем отличить от другого), информацию о котором необходимо хранить в базе данных. Сущностями могут быть люди, места, самолеты, рейсы, вкус, цвет и т.д. Необходимо различать такие понятия, как тип сущности и экземпляр сущности. Понятие тип сущности относится к набору однородных личностей, предметов, событий или идей, выступающих как целое. Экземпляр сущности относится к конкретной вещи в наборе. Например, типом сущности может быть ГОРОД, а экземпляром – Москва, Киев и т.д.

    • Атрибут – поименованная характеристика сущности. Его наименование должно быть уникальным для конкретного типа сущности, но может быть одинаковым для различного типа сущностей (например, ЦВЕТ может быть определен для многих сущностей: СОБАКА, АВТОМОБИЛЬ, ДЫМ и т.д.). Атрибуты используются для определения того, какая информация должна быть собрана о сущности. Примерами атрибутов для сущности АВТОМОБИЛЬ являются ТИП, МАРКА, НОМЕРНОЙ ЗНАК, ЦВЕТ и т.д. Здесь также существует различие между типом и экземпляром. Тип атрибута ЦВЕТ имеет много экземпляров или значений: Красный, Синий, Банановый, Белая ночь и т.д., однако каждому экземпляру сущности присваивается только одно значение атрибута.

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

    • Ключ – минимальный набор атрибутов, по значениям которых можно однозначно найти требуемый экземпляр сущности. Минимальность означает, что исключение из набора любого атрибута не позволяет идентифицировать сущность по оставшимся. Для сущности Расписание ключом является атрибут Номер_рейса или набор: Пункт_отправления, Время_вылета и Пункт_назначения (при условии, что из пункта в пункт вылетает в каждый момент времени один самолет).

    • Связь – ассоциирование двух или более сущностей. Если бы назначением базы данных было только хранение отдельных, не связанных между собой данных, то ее структура могла бы быть очень простой. Однако одно из основных требований к организации базы данных – это обеспечение возможности отыскания одних сущностей по значениям других, для чего необходимо установить между ними определенные связи. А так как в реальных базах данных нередко содержатся сотни или даже тысячи сущностей, то теоретически между ними может быть установлено более миллиона связей. Наличие такого множества связей и определяет сложность инфологических моделей.

    Требования, предъявляемые к инфологической модели

    • Адекватное, отображение предметной области

    • Недопущение неоднозначной трактовки модели

    • Четкое определение моделируемой предметной области (конечность модели)

    • Легкая расширяемость, обеспечивающая ввод новых данных без изменения ранее определенных, то же относят и к удалению данных

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

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

    • Применимость языка спецификаций модели как при ручном, так и при автоматизированном проектировании информационных систем

      1. ER – модель

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

    1) связи между объектами и наборами характеристических свойств, и таким образом определить сами объекты.

    2) связи между объектами, задающие характер и функциональную природу их взаимозависимости.

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

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

    Сущности подразделяются на сильные и слабые. Сущность является слабой, если ее существование зависит от другой сущности — сильной по отношению к ней.

    Свойства. Природа свойства, как характер связи свойства с сущностью (объектом), может быть различной. Рассмотрим основные виды свойств.

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

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

    Значения свойств могут быть постоянными — статическими или динамическими, т. е. меняться со временем. Свойство может быть неопределенным, если оно является динамическим, но его текущее значение еще не задано.

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

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

    Эта ассоциация всегда может существовать между разными сущностями или между сущностью и ею же самой (рекурсивная связь).

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

    Если каждый экземпляр сущности участвует, по крайней мере, в одном экземпляре связи, то такое участие этой сущности называется полным (или обязательным); в противном случае — неполным (или необязательным).

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

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

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

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

    Выделим основные сущности:

    - сущность «Модели»

    - сущность «Цеха»

    - сущность «Выпуск продукции»

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

    Определим ключи – уникальные идентификаторы экземпляров каждой сущности: для сущности «Модели» — это номер модели (Номер), для сущности «Выпуск продукции» - порядковый номер (Номер), для сущности «Цеха» - номер цеха (Номер).



    Рисунок 2 – Инфологическая модель

      1. Даталогическое проектирование базы данных

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

    • тип структуры данных, например реляционная модель;

    • выбранный тип СУБД, которая эту модель данных поддерживает;

    • технология и средства прикладного программирования;

    • конкретная компьютерная среда.

    На этом этапе необходимо установить соответствие между сущностями и характеристиками предметной области и отношениями и атрибутами в языке Access. Для этого нужно каждой сущности и характеристикам поставить в соответствие набор отношений (таблиц) и их атрибутов (полей).

    В результате получили следующие отношения:

    R1) «Модели» (Номер, Себестоимость, Цена, Время изготовления);

    R2) «Цеха» (Номер, Название, Руководитель, Штатная численность);

    R3) «Выпуск продукции» (Номер, Модель, Цех, Дата выпуска, Брак).



    Рисунок 3 – Модель данных

    1. Физическая реализация базы данных

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

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

    При разработке физической модели данных возникают вопросы: хорошо ли спроектированы таблицы? Правильно ли выбраны индексы? Насколько многопрограммного кода в виде триггеров и хранимых процедур необходимо разработать для поддержания целостности данных?

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

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

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

      1. Структура таблицы базы данных

    База данных состоит из справочных таблиц «Модели» и «Цеха», и связанной с ними таблицей «Выпуск продукции».

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

    Таблица 1. Структура таблиц РБД «Завод по изготовлению стиральных машин»

    Название таблицы

    Имя поля

    Тип данных

    Размер поля

    Примечание

    Модели

    Номер

    Счетчик

    Целое

    Ключ

    Название модели

    Текстовый

    25




    Себестоимость

    Числовой

    Действительное




    Цена

    Числовой

    Действительное




    Время для изготовления

    Числовой

    Целое




    Цеха

    Номер

    Счетчик

    Целое

    Ключ

    Название цеха

    Текстовый

    25




    Руководитель цеха

    Текстовый

    25




    Штатная численность

    Числовой

    Целое




    Продолжение Таблицы 1

    Название таблицы

    Имя поля

    Тип данных

    Размер поля

    Примечание

    Выпуск продукции

    Номер

    Счетчик

    Целое

    Ключ

    Модель

    Числовой

    Целое

    Внешний ключ

    Цех

    Числовой

    Целое

    Внешний ключ

    Дата выпуска

    Дата/время

    Краткий формат даты




    Наличие брака

    Текстовый

    5




    После того как были созданы поля таблицы, применены к ним свойства и заполнены атрибуты, мы составляем схему данных. Схема данных изображена на рисунке 4.



    Рисунок 4 – Связи между таблицами в БД

      1. Формы базы данных библиотеки

    При открытии приложения появляется главная форма информационной системы «Завод по производству стиральных машин» (рисунок 5).



    Рисунок 5 – Главная форма базы данных

    Форма имеет три вкладки, которые позволяют работать с основными сущностями базы данных: Выпуск продукции, Модели стиральных машин и Цеха производства. На всех вкладках находятся по две кнопки: «Добавить» и «Редактировать». Данные кнопки позволяют вносить новые сведения в базу данных или редактировать имеющиеся сведения.



    Рисунок 6 – Сведения о выпуске продукции

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

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

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



    Рисунок 7 – Сортировка сведений по номеру

    Для добавления новых сведений за текущий день необходимо нажать кнопку «Добавить». После данного действия, поля для ввода данных очищаются, и пользователь может внести туда данные и добавить их в базу данных.



    Рисунок 8 – Добавление данных

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

    После перехода программы в режим добавления записи, пользователь может либо заполнить все данные и добавить их в информационную систему, либо отказаться от их добавления, нажав кнопку «Отменить».

    Для редактирования данных необходимо нажать на кнопку «Редактирование». После этого программа переходит в режим редактирования с сохранением данных выбранной записи БД в полях для редактирования.



    Рисунок 9 – Редактирование информации

    После внесения изменений необходимо подтвердить данное действие нажатием кнопки «Применить».

    Аналогичным образом происходит работа со вкладками: Модели и Цеха.



    Рисунок 10 – Вкладка «Модели»



    Рисунок 11 – Вкладка «Цеха»

    Работа с данными вкладками осуществляется реже чем со вкладкой «Выпуск продукции», поэтому вкладка «Выпуск продукции» была размещена левее и открывается сразу после запуска приложения.

      1. Отчеты базы данных

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



    Рисунок 12 – Отчет

      1. Запросы базы данных

    В созданном приложении вывод информации из базы данных осуществляется с помощью SQL запросов.

    Для вывода данных о выпускаемой продукции выполняется запрос:

    select v.nomer as [Номер], m.model as [Модель], s.nazv as [Цех], dat_vypuska as [Дата выпуска], brak as [Брак]

    from vypusk v, modeli m, shop s

    where v.nomer_modeli=m.nomer and v.nomer_shop=s.nomer

    order by v.nomer

    При выполнении запроса на экран выведутся столбцы: Номер, Модель, Цех, Дата выпуска и Брак. Это описано в разделе Select. Запрос использует три таблицы из базы данных, описанных в разделе From. Соединение таблиц по ключу описано в разделе Where запроса. Данные выводятся в сортированном виде. Сортировка описывается в разделе Order by и происходит по полю Номер выпуска продукции.

    Результат выполнения запроса показан на рисунке 13.



    Рисунок 13 – Результат запроса для вывода выпускаемой продукции на экран

    Для вывода данных о моделях стиральных машин выполняется запрос:

    select nomer as [Номер], model as [Модель], sebestoimost as [Себестоимость], price as [Цена], vr_izgot as [Время изготовления]

    from modeli

    Данный запрос выводит информацию только из одной таблицы.

    Для вывода данных о цехах, производящих стиральные машины выполняется запрос:

    select nomer as [Номер], nazv as [Название цеха], rukovoditel as [Руководитель], shtat as [Штатная численность]

    from shop

    Данный запрос выводит информацию только из одной таблицы Цеха.

    Добавление данных в базу данных так же происходит с помощью запросов. Например, приведем запрос для добавления записи в таблицу Модели:

    insert into modeli(model, sebestoimost, price, vr_izgot)

    values('+#39+edt1.Text+#39+','+edt2.Text+', '+edt3.Text+','+edt4.Text

    В данном запросе перечисляются поля, в которые будет осуществляться добавление и значения, которые необходимо добавить.

    Поле Nomer имеет тип – Счетчик, то есть при добавлении новой записи оно увеличивается автоматически на единицу. Следовательно перечислять его при добавлении не нужно.

    Редактирование информации, так же производится с помощью запросов. Запрос на обновлении записей таблицы модели:

    update modeli set model='+#39+edt1.Text+#39+' ,sebestoimost='+edt2.Text+', price='+edt3.Text+', vr_izgot='+edt4.Text);

    where nomer='+qry2.fieldbyname('Номер').AsString

    В данном запросе указывается таблица, в которой обновляется информация и перечисляются пары «поле=значение», которые будут обновлены после выполнения запроса.

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

    select s.nazv as [Цех], COUNT(*) as [Кол-во стиральных машин]

    from vypusk v, shop s

    where v.nomer_shop=s.nomer and dat_vypuska between :param and :param2

    group by s.nazv

    Данный запрос группирует всю найденную информацию по цехам и подсчитывает количество выпущенных стиральных машин (рисунок 14).



    Рисунок 14 – Результат выполнения запроса

    Заключение:

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

    При разработке базы данных можно выделить несколько уровней моделирования:

    • Анализ предметной области;

    • Инфологическое проектирование;

    • Даталогическое проектирование;

    • Физическая модель данных;

    • Собственно база данных и приложения.

    В базе данных используются следующие объекты:

    • таблицы для сохранения данных;

    • запросы для поиска и извлечения только требуемых данных;

    • формы для просмотра, добавления и изменения данных в таблицах;

    • отчеты для анализа и печати данных в определенном формате.

    Основная литература:

    1. Марков А.С. Базы данных. Введение в теорию и методологию Лисовский К. Ю., Москва, 2004;

    2. Тиори Т., Фрай Дж. Проектирование структур баз данных : В 2-х кн. Пер. с англ. / М.: Мир, 2005;

    3. Голицина О. Л. Базы данных / Голицина О. Л., Максимов Н. В., Попов И. И. – М.: Форум, 2003;

    4. Бемер С., Фратер Г. Microsoft Access для пользователя / Микап, Москва 2004;

    5. Коннолли Т., Бегг К. Базы данных. Проектирование, реализация и сопровождение / Москва, Питер, Киев, 2003;

    6. Мейер, М. Теория реляционных баз данных / М. Мейер – М.: Мир, 2008

    7. Хаббард, Дж. Автоматизированное проектирование баз данных / Хаббард Дж. – М.: Мир, 2005;

    8. Бойко, В. В. Проектирование баз данных информационных систем / Бойко В.В., Савинков В.М. – М.: Финансы и статистика, 2007;

    9. Бакаревич, Ю. Б. Самоучитель Microsoft Access 2007 / Бакаревич Ю.Б., Пушкина Н.В. – СПб.: БХВ-Петербург, 2007.


    написать администратору сайта