1) Шифр изделия, шифр материала, потребность в материале на одно изделие.
2) Номер цеха, шифр изделия, план выпуска в день.
Формы документов:
1) Потребность в материалах на месяц для произвольно заданного цеха.
13. Определение потребностей в сырье, материалах, изделиях.
Структура файлов базы данных- та же , что и в варианте 21.
Формы документов:
1) Потребность в материалах на месяц (квартал, полугодие) и в целом на предприятие в заданном сырье, материале, изделиях .для произвольно зад
13. Ведение картотеки книг, документов, материалов и т.п.
Структура файлов базы данных:
1) Шифр издания, автор, наименование.
2) Шифр издания, издательство, год издания, тематика.
Формы документов:
1) Книги по тематике: шифр, автор, наименование, издательство, год издания.
14. Организация и управление соревнованиями команд, участников по видам спорта.
Структура файлов базы данных:
1) Справочный файл условных номеров команд, названий команд, участвующих в состязаниях: условный номер, название команды, характеристики команды.
2) Файл результатов состязаний: дата игры, номер команды, результат (счет), количество очков в очередной игре (встрече), общее число очков.
Формы документов:
Таблица состязаний: команда, место, количество игр, выигрышей, проигрышей, ничьих, результаты, очки.
15. Продажа автомобилей
Структура файлов базы данных:
1) Справочный файл марок и моделей, автомобилей, их характеристик, стоимости.
2) Список и данные менеджеров фирмы
3) Данные о продажах автомобилей каждым менеджером по датам и моделям.
Формы документов:
1) Список продаж каждым менеджером на заданное число,
2) Количество проданных автомобилей каждой модели на заданное число.
3) Наличие непроданных автомобилей каждой марки.
16. Ведение договоров на выпускаемую предприятием продукцию
Структура файлов базы данных:
1) список договоров, данные заказчика (юридическое или физическое лицо, адрес, наименование организации (фамилия, И.О., банковские реквизиты и т.д.), дата поставки, дата заключения договора, заказанная продукция..
2) Номенклатура предлагаемой продукции: наименование, единица измерения, цены, шифр.
Формы документов:
1) список полностью оплаченных договоров: наименование и количество поставляемой продукции.
2) Список договоров с предоплатой: сумма оплаты, сумма долга, сроки поставки.
3) Список просроченных договоров (оплата не поступила к сроку поставки).
17. Обслуживание клиентов по системе заказов.
Структура файлов базы данных
1) Список клиентов: юридическое или физическое лицо, адрес, наименование организации (фамилия, И.О., банковские реквизиты и т.д.),
2) Состав предлагаемых услуг , их прейскурант или номенклатура.
3) Заказ: дата поставки, дата заключения заказа, заказанная продукция, дата на которую заказ был выполнен.
Формы документов:
1) список заказов в порядке возрастания даты выполнения: даты . . . . . . .заказа. . . . .исполнения, атрибуты клиента, предмет заказа.
2) Список заказов просроченных на заданное число.
3) Список выполненных на данное число заказов.
18. Ведение библиотечного учета.
Структура файлов базы данных
1) список имеющейся литературы: наименование, автор, дата издания, издательство.
2) Список читателей: фамилия, И.О., адрес, возраст, пол, место работы или учебы..
3) Список взятой каждым читателем литературы с датами выдачи и возврата.
Формы документов:
1) Список читателей задержавших возврат литературы к заданному сроку: список невозвращенных данным читателем книг,
2) Список отсутствующей в библиотеке литературы с указанием читателя и предполагаемого срока возврата.
19. Успеваемость студентов вуза
Структура файлов базы данных
1) Список студентов по группам: фамилия, И., О., пол, возраст, курс
2) Список предметов: наименование предмета, ведущий преподаватель.
3) список преподавателей: фамилия, И., О.
Формы документов:
1) Список студентов данной группы : фамилия, И., О.предмет, отметка, преподаватель,
Сгруппировать по курсам.
20. Автобусный парк.
Структура файлов базы данных
1) Список водителей: фамилия, И., О.пол, возраст, адрес, телефон
2) Список автобусов: марка, номер.
3) Список маршрутов: наименование, временные характеристики, длительность.
Формы документов:
1) На каком маршруте, какой водитель в какой день недели задействован.
3.ПОРЯДОК ВЫПОЛНЕНИЯ ДОМАШНЕГО ЗАДАНИЯ
Широкое распространение реляционных СУБД и их использование в самых разнообразных приложениях показывает, что реляционная модель данных достаточна для моделирования предметных областей. Однако проектирование реляционной базы данных в терминах отношений на основе рассмотренного нами ранее механизма нормализации (см. главу 4 «Реляционные базы данных») часто представляет собой очень сложный и неудобный для проектировщика процесс. Это обусловлено некоторой ограниченностью реляционной модели данных, которая особенно ярко проявляется в следующих аспектах:
- реляционная модель не предоставляет достаточных средств для представления смысла данных. Проектировщик должен независимым от модели способом представлять семантику реальной предметной области. Примером данного ограничения может служить представление ограничений целостности;
- в ряде случаев предметную область трудно моделировать на основе плоских таблиц. Сложности могут возникнуть на начальной стадии проектирования при описании предметной области в виде одной (возможно, даже ненормализованной) таблицы;
- хотя весь процесс проектирования происходит на основе учета зависимостей, реляционная модель не содержит никаких средств для представления этих зависимостей;
- несмотря на то что процесс проектирования начинается с выделения некоторых объектов (сущностей) предметной области, существенных для приложения, и выявления связей между этими сущностями, реляционная модель данных не предлагает какого-либо аппарата для разделения сущностей и связен.
Для преодоления ограничении реляционной модели и обеспечения потребности проектировщиков баз данных в более удобных и мощных средствах моделирования предметной области проектирование баз данных обычно выполняется не в терминах реляционной модели, а с использованием концептуальных моделей предметной области.
Обычно различают концептуальные модели двух видов:
- объектно-ориентированные модели, в которых сущности реального мира представляются в виде объектов, а не записей реляционных таблиц;
- семантические модели, отражающие значения реальных сущностей и отношений. Объектно-ориентированную модель можно рассматривать как результат объединения семантической модели данных и объектно-ориентированного языка программирования.
Несмотря на то, что в последнее время все большее распространение получают объектно-ориентированные модели, не снижается и значение семантических моделей. Концептуальное моделирование баз данных на основе семантических моделей поддерживается во всех известных CASE-средствах (например, таких как ERWin и Power Designer). Кроме того, семантические модели более просты для понимания, особенно при проектировании сравнительно небольших баз данных.
Как и реляционная модель, любая развитая семантическая модель данных включает структурную, манннуляционную и целостную части. Главным назначением семантических моделей является обеспечение возможности выражения семантики данных.
Цель семантического моделирования — обеспечение наиболее естественных для человека способов сбора и представления той информации, которую предполагается хранить в создаваемой базе данных. Поэтому семантическую модель данных пытаются строить по аналогии с естественным языком (последний не может быть использован в чистом виде из-за сложности компьютерной обработки текстов и неоднозначности любого естественного языка). Основными конструктивными элементами семантических моделей являются сущности, связи между ними и их свойства (атрибуты).
Одной из наиболее популярных семантических моделей данных является модель «сущность-связь» (часто называемая также ER-моделью — по первым буквам английских слов Entity (сущность) и Relation (связь)).
На использовании разновидностей ER-моделн основано большинство современных подходов к проектированию баз данных (главным образом, реляционных). Модель была предложена Ченом в 1976 г. Моделирование предметной области базируется на использовании графических диаграмм, включающих небольшое число разнородных компонентов. В связи с наглядностью представления концептуальных схем баз данных ER-модели получили широкое распространение в CASE-средствах, предназначенных для автоматизированного проектирования реляционных баз данных.