Размещено на http://www.allbest.ru/

КУРСОВАЯ РАБОТА

Разработка базы данных учёта пропусков учащихся



СОДЕРЖАНИЕ

ВВЕДЕНИЕ

1. ЭТАПЫ ПРОЕКТИРОВАНИЯ БАЗЫ ДАННЫХ

1.1 Общие сведения об этапах проектирования

1.2 Концептуальное (инфологическое) проектирование

1.3 Логическое проектирование БД

1.4 Физическое проектирование БД

2. ПРОЕКТИРОВАНИЕ БАЗЫ ДАННЫХ УЧЕТА ПРОПУСКОВ УЧАЩИХСЯ

2.1 Концептуальное проектирование

2.2 Логическое проектирование

2.3 Физическое проектирование

ЗАКЛЮЧЕНИЕ

СПИСОК ЛИТЕРАТУРЫ



ВВЕДЕНИЕ

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

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

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

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

2. Обеспечение ограничений (на объёмы внешней и оперативной памяти и другие ресурсы вычислительной системы).

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

4. Защита данных (от сбоев и несанкционированного доступа).

5. Простота и удобство эксплуатации.

6. Гибкость, т.е. возможность развития и адаптации к изменениям программного обеспечения или требований пользователей.

Удовлетворение первых 4-х требований обязательно для принятия проекта.

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

Процесс проектирования БД включает в себя следующие этапы:

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

2. Информационно-логическое (концептуальное) проектирование.

3. Логическое проектирование БД.

4. Физическое проектирование БД.

Объект: База данных.

Предмет: База данных учета успеваемости студентов.

Цель: Спроектировать базу данных по учету пропусков занятий учащимися.

Задачи:

1. Проанализировать предметную область.

2. Спроектировать базу данных по учету пропусков.

3. Сделать выводы по анализируемой области.



1. ЭТАПЫ ПРОЕКТИРОВАНИЯ БАЗЫ ДАННЫХ

1.1 Общие сведения об этапах проектирования

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

· используемых методов анализа предметной области;

· правил именования и обозначения объектов ПО, атрибутов и связей;

· содержания и формата создаваемых ими документов.

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

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

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

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

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

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

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

1.2 Концептуальное (инфологическое) проектирование

Инфологический подход не предоставляет формальных способов моделирования реальности, однако он закладывает основы методологии проектирования БД.

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

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

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

Существуют разные подходы к инфологическому проектированию.

1. Функциональный подход к проектированию БД.

Этот метод является наиболее распространённым. Он реализует принцип «от задач» и применяется в том случае, когда известны функции некоторой группы лиц или комплекса задач, для обслуживания информационных потребностей которых создаётся рассматриваемая БД.

2. Предметный подход к проектированию БД.

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

3. Проектирование с использованием метода «сущность-связь».

Метод «сущность-связь» (Entity-Relation, ER-method) был разработан в 1976 г. П.Ченом (Chen P.P.). Он является комбинацией двух предыдущих и обладает достоинствами обоих. Этап инфологического проектирования начинается с моделирования ПО. Проектировщик разбивает предметную область на ряд локальных областей, каждая из которых (в идеале) включает в себя информацию, достаточную для обеспечения информационных потребностей одной группы будущих пользователей или решения отдельной задачи. Каждое локальное представление моделируется отдельно, а затем выполняется их объединение. Выбор локального представления зависит от масштабов предметной области. Обычно она разбивается на локальные области так, чтобы каждая из них соответствовала отдельному внешнему приложению и содержала 6-7 сущностей (т.е. объектов, о которых в системе будет накапливаться информация).

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

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

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

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

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

· объединение в единое целое фрагментарных представлений о различных свойствах одного и того же объекта;

· введение абстрактных понятий, удобных для решения задач системы, установление их связи с более конкретными понятиями модели;

· образование классов и подклассов подобных объектов (например, класс «изделие» и подклассы типов изделий, производимых на предприятии).

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

1.Идентичность. Два или более элементов модели идентичны, если они имеют одинаковое семантическое значение.

2.Агрегация. Позволяет рассматривать связь между элементами как новый элемент. Например, связьэкзаменмежду сущностямистудент,дисциплина,преподавательможет быть представлена агрегированной сущностьюэкзаменс атрибутамиНазвание дисциплины,Фамилия преподавателя,Фамилия студента,Оценка.

3.Обобщение. Позволяет образовывать многоуровневую иерархию обобщений. Например, в объединяемых представлениях присутствуют следующие сущности:

Детали собственного производства

Детали покупные

Сборочные единицы покупные

Сборочные единицы собственного производства

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

Рисунок 1.1 Использование обобщений при объединении

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

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

На этапе анализа предметной области также решаются следующие задачи:

1. Определение правил (ограничений целостности), которым должны удовлетворять сущности предметной области, атрибуты сущностей и связи между ними. Часть этих правил реализуется в схеме базы данных (возможности реализации ограничений целостности в схеме базы данных определяются моделью данных той СУБД, которая будет выбрана для реализации проекта). Остальные правила реализуются с помощью программного обеспечения.

2. Выделение групп пользователей системы. Каждая группа выполняет определённые задачи и обладает разными правами доступа к системе.

3. Создание внешней спецификации тех функций (процессов), которые эта система будет выполнять. Например, для той же библиотечной системы это задачи поиска книг (по определённым критериям), выдачи/приёма книг, определение списка должников и т.д.

4. Семантическая объектная модель.

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

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

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

1.3 Логическое проектирование БД

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

Логическое проектирование базы данных дляреляционной модели:

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

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

· Определение набора отношений исходя из структуры локальной логической модели данных.

· Проверка отношений с помощью правил нормализации.

· Проверка соответствия отношений требованиям пользовательских транзакций.

· Определение требований поддержки целостности данных.

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

· Создание и проверка глобальной логической модели данных.

· Слияние локальных логических моделей данных в единую глобальную модель данных.

· Проверка глобальной логической модели данных.

· Проверка возможностей расширения модели в будущем.

· Обсуждение глобальной логической модели данных с пользователями.

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

· Каждое отношение соответствует одной сущности предметной области и в него вносятся все атрибуты объекта, связанные с ним отношением 1:1.

· Связь типа 1:n реализуется с помощью внешнего ключа.

· Для реализации связи типа n:m между сущностями вводится дополнительное отношение, содержащее комбинации первичных ключей связанных отношений и атрибуты (свойства) этой связи.

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

Выбор ключей.

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

Иногда бывает, что предполагаемый первичный ключ таблицы оказывается не достаточно уникальным, когда мы начинаем учитывать реализацию его в реляционной базе данных. Возьмем, к примеру, событие. Дата и время наступления события будут гарантированно уникальными, если определить их с достаточной степенью точности. Однако в базе данных Oracleвремя хранится с точностью до секунды, а наличие двух событий в секунду - явление весьма распространенное.

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

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

Типы данных

Любые данные, используемые в программировании, имеют свои типы данных.

Реляционная модель требует, чтобы типы используемых данных былипростыми.

Простые, или атомарные, типы данныхне обладают внутренней структурой. Данные такого типа называютскалярами. К простым типам данных относятся следующие типы:

Логический.

Строковый.

Численный.

Различные языки программирования могут расширять и уточнять этот список, добавляя такие типы как:

Целый.

Вещественный.

Дата.

Время.

Денежный.

Перечислимый.

Интервальный.

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

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

Первая нормальная форма (1НФ). Отношение находится в 1НФ, тогда и только тогда, когда не одно из полей не содержит более одного значения.

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

Для того чтобы привести отношение ко 2НФ, нужно:

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

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

Третья нормальная форма (3НФ). Отношение находится в 3НФ, если она удовлетворяет определению 2-ой НФ и не одно из её неключевых полей не зависит функционально от любого другого неключевого поля.

1.4 Физическое проектирование БД

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

Фактически проектирование БД имеет итерационный характер. В процессе функционирования системы становится возможным измерение её реальных характеристик, выявление «узких» мест. И если система не отвечает предъявляемым к ней требованиям, то обычно она подвергается реорганизации, т.е. модификации первоначально созданного проекта.

Методология физического проектирования базы данных

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

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



2. ПРОЕКТИРОВАНИЕ БАЗЫ ДАННЫХ УЧЕТА ПРОПУСКОВ УЧАЩИХСЯ

2.1 Концептуальное проектирование

Таблица 2.1 Сущности

Сущность	Атрибуты	Тип данных
Ученики	Идентификатор Фамилия Имя Отчество Класс	Числовой (4) Текстовый (32) Текстовый (20) Текстовый (50) Числовой (1)
Преподаватели	Идентификатор Фамилия Имя Отчество Предмет	Числовой (3) Текст (32) Текст (20) Текст (50) Числовой (3)
Предмет	Идентификатор Название	Числовой (3) Текст (70)
Журнал	Студент Преподаватель Дата Кол-во пропусков	Числовой (4) Числовой (3) Дата Числовой (1)

Таблица 2.2 Связи сущностей

Главный	Атрибут	Ведомый	Тип
Журнал	Ученики Преподаватели	Идентификатор Идентификатор	Ученики Преподаватели	М:1 М:1
Преподаватель	Предмет	Идентификатор	Предмет	М:М

2.2 Логическое проектирование

Таблица 2.3 Uchenic

iduchenic	familija	imja	otchestvo	klass



Таблица 2.4 Prepodavatel

idprepodavatel	familija	imja	otchestvo	predmet

Таблица 2.5 Predmet

idpredmet	nazvanie

Таблица 2.6 Journal

idjournal	prepodavatel	data	kol-vo propusk

2.3 Физическое проектирование

CREATE SCHEMA IF NOT EXISTS `absences` DEFAULT CHARACTER SET utf8 COLLATE utf8_general_ci ;

USE `absences`;

CREATE TABLE IF NOT EXISTS `absences`.`students` (

`id` MEDIUMINT UNSIGNED NOT NULL,

`first_name` VARCHAR(20) NOT NULL,

`last_name` VARCHAR(30) NOT NULL,

`group` CHAR(3) NOT NULL,

PRIMARY KEY (`id`))

ENGINE = InnoDB;

CREATE TABLE IF NOT EXISTS `absences`.`valids` (

`students_id` MEDIUMINT UNSIGNED NOT NULL,

`month` TINYINT(2) UNSIGNED NOT NULL,

`day` TINYINT(2) UNSIGNED NOT NULL,

`value` TINYINT(2) UNSIGNED ZEROFILL NOT NULL,

PRIMARY KEY (`students_id`, `month`, `day`),

INDEX `fk_valids_students_idx` (`students_id` ASC),

CONSTRAINT `fk_valids_students`

FOREIGN KEY (`students_id`)

REFERENCES `absences`.`students` (`id`)

ON DELETE NO ACTION

ON UPDATE NO ACTION)

ENGINE = InnoDB;

CREATE TABLE IF NOT EXISTS `absences`.`invalids` (

`students_id` MEDIUMINT UNSIGNED NOT NULL,

`month` TINYINT(2) UNSIGNED NOT NULL,

`day` TINYINT(2) UNSIGNED NOT NULL,

`value` TINYINT(2) UNSIGNED ZEROFILL NOT NULL,

PRIMARY KEY (`students_id`, `month`, `day`),

INDEX `fk_invalids_students1_idx` (`students_id` ASC),

CONSTRAINT `fk_invalids_students1`

FOREIGN KEY (`students_id`)

REFERENCES `absences`.`students` (`id`)

ON DELETE NO ACTION

ON UPDATE NO ACTION)

ENGINE = InnoDB;



ЗАКЛЮЧЕНИЕ

В процессе работы над курсовой работой была создана база данных «пропусков учащихся». В результате проведена следующая работа:

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

На основе инфологической модели спроектирована физическая модель БД, результатом которой является схема данных.

Рассмотрена СУБД, в которой выполнялось создание базы данных.

Спроектированы таблицы в режиме SQL.

Спроектированы запросы в режиме SQL.

проектирование база инфологический концептуальный



СПИСОК ЛИТЕРАТУРЫ

1.Бьюли А. Изучаем SQL / А. Бьюли. - М.: Символ-Плюс, 2007. - 312 с.

2.ВолохаА. Microsoft SQL Server 2005. Новые возможности / А. Волоха. - С.-П.: Питер, 2010. - 304 с.

3.Днепров А. Видеосамоучитель. Microsoft Access 2007 / А. Днепров. - С.-П.: Питер, 2008. - 240 с.

4. Карпова Т.С. Базы данных: модели, разработка, реализация / Т.С. Карпова. - СПб.: Питер, 2008. - 304 с. - ISBN 5-272-00278-4.

5. Конспект лекций «Базы данных»

6.Михеева В. Microsoft Access 2003 / В. Михеева, И. Харитонова. - С.-П.: БХВ-Петербург, 2009. - 1072 с. 1. Microsoft SQL Server 7 для профессионалов. - СПб.: Питер, 2000. - 896 с.

7. Роберт Виейра. Программирование баз данных Microsoft SQL Server 2005. Базовый курс. - М.:Вильямс, 2003. - 848 с.

Размещено на Allbest.ru

...