МЕНЮ


Фестивали и конкурсы
Семинары
Издания
О МОДНТ
Приглашения
Поздравляем

НАУЧНЫЕ РАБОТЫ


  • Инновационный менеджмент
  • Инвестиции
  • ИГП
  • Земельное право
  • Журналистика
  • Жилищное право
  • Радиоэлектроника
  • Психология
  • Программирование и комп-ры
  • Предпринимательство
  • Право
  • Политология
  • Полиграфия
  • Педагогика
  • Оккультизм и уфология
  • Начертательная геометрия
  • Бухучет управленчучет
  • Биология
  • Бизнес-план
  • Безопасность жизнедеятельности
  • Банковское дело
  • АХД экпред финансы предприятий
  • Аудит
  • Ветеринария
  • Валютные отношения
  • Бухгалтерский учет и аудит
  • Ботаника и сельское хозяйство
  • Биржевое дело
  • Банковское дело
  • Астрономия
  • Архитектура
  • Арбитражный процесс
  • Безопасность жизнедеятельности
  • Административное право
  • Авиация и космонавтика
  • Кулинария
  • Наука и техника
  • Криминология
  • Криминалистика
  • Косметология
  • Коммуникации и связь
  • Кибернетика
  • Исторические личности
  • Информатика
  • Инвестиции
  • по Зоология
  • Журналистика
  • Карта сайта
  • Реляционные базы данных-правила формирования отношений

    Характер связей между сущностями не ограничивается перечисленными.

    Существуют и более сложные связи:

    . множество связей между одними и теми же сущностями

    [pic]

    (пациент, имея одного лечащего врача, может иметь также несколько

    врачей-консультантов; врач может быть лечащим врачом нескольких пациентов и

    может одновременно консультировать несколько других пациентов);

    . тренарные связи

    [pic]

    (врач может назначить несколько пациентов на несколько анализов, анализ

    может быть назначен несколькими врачами нескольким пациентам и пациент

    может быть назначен на несколько анализов несколькими врачами);

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

    сложна.

    3 Классификация сущностей

    Существуют три основные класса сущностей: стержневые, ассоциативные и

    характеристические, а также подкласс ассоциативных сущностей – обозначения.

    Стержневая сущность (стержень) – это независимая сущность (несколько

    подробнее она будет определена ниже).

    В рассмотренных ранее примерах стержни – это "Студент", "Квартира",

    "Мужчины", "Врач", "Брак" и другие, названия которых помещены в

    прямоугольники. Ассоциативная сущность (ассоциация) – это связь вида

    "многие-ко-многим" ("-ко-многим" и т.д.) между двумя или более сущностями

    или экземплярами сущности . Ассоциации рассматриваются как полноправные

    сущности:

    - они могут участвовать в других ассоциациях и обозначениях точно так

    же, как стержневые сущности;

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

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

    атрибутов, характеризующих связь.

    Характеристическая сущность (характеристика) – это связь вида "многие-к-

    одной" или "одна-к-одной" между двумя сущностями (частный случай

    ассоциации). Единственная цель характеристики в рамках рассматриваемой

    предметной области состоит в описании или уточнении некоторой другой

    сущности. Необходимость в них возникает в связи с тем, что сущности

    реального мира имеют иногда многозначные свойства. Муж может иметь

    несколько жен , книга – несколько характеристик переиздания (исправленное,

    дополненное, переработанное, ...) и т.д.

    Существование характеристики полностью зависит от характеризуемой

    сущности: женщины лишаются статуса жен, если умирает их муж.

    Обозначающая сущность или обозначение – это связь вида "многие-к-одной"

    или "одна-к-одной" между двумя сущностями и отличается от характеристики

    тем, что не зависит от обозначаемой сущности.

    В заключение рассмотрим пример построения инфологической модели базы

    данных "Питание", где должна храниться информация о блюдах, их ежедневном

    потреблении, продуктах, из которых приготавливаются эти блюда, и

    поставщиках этих продуктов. Информация будет использоваться поваром и

    руководителем небольшого предприятия общественного питания, а также его

    посетителями.

    С помощью указанных пользователей выделены следующие объекты и

    характеристики проектируемой базы:

    1. Блюда, для описания которых нужны данные, входящие в их кулинарные

    рецепты: номер блюда (например, из книги кулинарных рецептов),

    название блюда, вид блюда (закуска, суп, горячее и т.п.), рецепт

    (технология приготовления блюда), выход (вес порции), название,

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

    2. Для каждого поставщика продуктов: наименование, адрес, название

    поставляемого продукта, дата поставки и цена на момент поставки.

    3. Ежедневное потребление блюд (расход): блюдо, количество порций, дата.

    Анализ объектов позволяет выделить:

    . стержни Блюда, Продукты и Города;

    . ассоциации Состав (связывает Блюда с Продуктами) и

    Поставки (связывает Поставщиков с Продуктами);

    . обозначение Поставщики;

    . характеристики Рецепты и Расход.

    [pic]

    Рисунок 2. Инфологическая модель базы данных "Питание"

    4 Первичные и внешние ключи

    Напомним, что ключ или возможный ключ – это минимальный набор

    атрибутов, по значениям которых можно однозначно найти требуемый экземпляр

    сущности. Минимальность означает, что исключение из набора любого атрибута

    не позволяет идентифицировать сущность по оставшимся. Каждая сущность

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

    первичный ключ. При выборе первичного ключа следует отдавать предпочтение

    несоставным ключам или ключам, составленным из минимального числа

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

    значениями (предпочтительнее использовать целочисленные атрибуты). Так, для

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

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

    дополнительных атрибутов, так как не исключено появление в группе двух

    студентов (а чаще студенток) с одинаковыми фамилиями, именами и отчествами.

    Плохо также использовать в качестве ключа не номер блюда, а его название,

    например, " Закуска из плавленых сырков "Дружба" с ветчиной и соленым

    огурцом" или "Заяц в сметане с картофельными крокетами и салатом из красной

    капусты".

    Не допускается, чтобы первичный ключ стержневой сущности (любой

    атрибут, участвующий в первичном ключе) принимал неопределенное значение.

    Иначе возникнет противоречивая ситуация: появится не обладающий

    индивидуальностью, и, следовательно не существующий экземпляр стержневой

    сущности. По тем же причинам необходимо обеспечить уникальность первичного

    ключа.

    Теперь о внешних ключах:

    . Если сущность С связывает сущности А и В, то она должна включать

    внешние ключи, соответствующие первичным ключам сущностей А и В.

    . Если сущность В обозначает сущность А, то она должна включать внешний

    ключ, соответствующий первичному ключу сущности А.

    Таким образом, при рассмотрении проблемы выбора способа представления

    ассоциаций и обозначений в базе данных основной вопрос, на который следует

    получить ответ: "Каковы внешние ключи?". И далее, для каждого внешнего

    ключа необходимо решить три вопроса:

    1. Может ли данный внешний ключ принимать неопределенные значения (NULL-

    значения)? Иначе говоря, может ли существовать некоторый экземпляр сущности

    данного типа, для которого неизвестна целевая сущность, указываемая внешним

    ключом? В случае поставок это, вероятно, невозможно – поставка,

    осуществляемая неизвестным поставщиком, или поставка неизвестного продукта

    не имеют смысла. Но в случае с сотрудниками такая ситуация однако могла бы

    иметь смысл – вполне возможно, что какой-либо сотрудник в данный момент не

    зачислен вообще ни в какой отдел. Заметим, что ответ на данный вопрос не

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

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

    представлена в рассматриваемой базе данных. Подобные замечания имеют

    отношение и к вопросам, обсуждаемым ниже.

    2. Что должно случиться при попытке УДАЛЕНИЯ целевой сущности, на

    которую ссылается внешний ключ? Например, при удалении поставщика, который

    осуществил по крайней мере одну поставку. Существует три возможности:

    |КАСКАДИРУЕТСЯ |Операция удаления "каскадируется" с тем, |

    | |чтобы удалить также поставки этого |

    | |поставщика. |

    |ОГРАНИЧИВАЕТСЯ |Удаляются лишь те поставщики, которые еще не |

    | |осуществляли поставок. Иначе операция |

    | |удаления отвергается. |

    |УСТАНАВЛИВАЕТСЯ |Для всех поставок удаляемого поставщика |

    | |NULL-значение внешний ключ устанавливается в |

    | |неопределенное значение, а затем этот |

    | |поставщик удаляется. Такая возможность, |

    | |конечно, неприменима, если данный внешний |

    | |ключ не должен содержать NULL-значений. |

    3. Что должно происходить при попытке ОБНОВЛЕНИЯ первичного ключа

    целевой сущности, на которую ссылается некоторый внешний ключ? Например,

    может быть предпринята попытка обновить номер такого поставщика, для

    которого имеется по крайней мере одна соответствующая поставка. Этот случай

    для определенности снова рассмотрим подробнее. Имеются те же три

    возможности, как и при удалении:

    |КАСКАДИРУЕТСЯ |Операция обновления "каскадируется" с тем, |

    | |чтобы обновить также и внешний ключ |

    | |впоставках этого поставщика. |

    |ОГРАНИЧИВАЕТСЯ |Обновляются первичные ключи лишь тех |

    | |поставщиков, которые еще не осуществляли |

    | |поставок. Иначе операция обновления |

    | |отвергается. |

    |УСТАНАВЛИВАЕТСЯ |Для всех поставок такого поставщика |

    | |NULL-значение внешний ключ устанавливается в |

    | |неопределенное значение, а затем обновляется |

    | |первичный ключ поставщика. Такая возможность,|

    | |конечно, неприменима, если данный внешний |

    | |ключ не должен содержать NULL-значений. |

    Таким образом, для каждого внешнего ключа в проекте проектировщик базы

    данных должен специфицировать не только поле или комбинацию полей,

    составляющих этот внешний ключ, и целевую таблицу, которая идентифицируется

    этим ключом, но также и ответы на указанные выше вопроса (три ограничения,

    которые относятся к этому внешнему ключу).

    Наконец, о характеристиках – обозначающих сущностях, существование

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

    внешним ключом в таблице, соответствующей этой характеристике. Но три

    рассмотренные выше ограничения на внешний ключ для данного случая должны

    специфицироваться следующим образом:

    NULL-значения не допустимы

    УДАЛЕНИЕ ИЗ (цель) КАСКАДИРУЕТСЯ

    ОБНОВЛЕНИЕ (первичный ключ цели) КАСКАДИРУЕТСЯ

    Указанные спецификации представляют зависимость по существованию

    характеристических сущностей.

    5 Ограничения целостности

    Целостность (от англ. integrity – нетронутость, неприкосновенность,

    сохранность, целостность) – понимается как правильность данных в любой

    момент времени. Но эта цель может быть достигнута лишь в определенных

    пределах: СУБД не может контролировать правильность каждого отдельного

    значения, вводимого в базу данных (хотя каждое значение можно проверить на

    правдоподобность). Например, нельзя обнаружить, что вводимое значение 5

    (представляющее номер дня недели) в действительности должно быть равно 3. С

    другой стороны, значение 9 явно будет ошибочным и СУБД должна его

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

    должны принадлежать набору (1,2,3,4,5,6,7).

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

    данных от неверных изменений или разрушений (не путать с незаконными

    изменениями и разрушениями, являющимися проблемой безопасности).

    Современные СУБД имеют ряд средств для обеспечения поддержания целостности

    (так же, как и средств обеспечения поддержания безопасности).

    Выделяют три группы правил целостности:

    1. Целостность по сущностям.

    2. Целостность по ссылкам.

    3. Целостность, определяемая пользователем.

    В п. 2.3 была рассмотрена мотивировка двух правил целостности, общих

    для любых реляционных баз данных.

    1. Не допускается, чтобы какой-либо атрибут, участвующий в первичном ключе,

    принимал неопределенное значение.

    2. Значение внешнего ключа должно либо:

    - быть равным значению первичного ключа цели;

    - быть полностью неопределенным, т.е. каждое значение атрибута,

    участвующего во внешнем ключе должно быть неопределенным.

    Для любой конкретной базы данных существует ряд дополнительных

    специфических правил, которые относятся к ней одной и определяются

    разработчиком.

    Глава 3. Реляционный подход.

    7 Реляционная структура данных

    В конце 60-х годов появились работы, в которых обсуждались возможности

    применения различных табличных даталогических моделей данных, т.е.

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

    данных. Наиболее значительной из них была статья сотрудника фирмы IBM д-ра

    Э.Кодда (Codd E.F., A Relational Model of Data for Large Shared Data Banks.

    CACM 13: 6, June 1970), где, вероятно, впервые был применен термин

    "реляционная модель данных".

    Будучи математиком по образованию Э.Кодд предложил использовать для

    обработки данных аппарат теории множеств (объединение, пересечение,

    разность, декартово произведение). Он показал, что любое представление

    данных сводится к совокупности двумерных таблиц особого вида, известного в

    математике как отношение – relation (англ.).

    Наименьшая единица данных реляционной модели – это отдельное атомарное

    (неразложимое) для данной модели значение данных. Так, в одной предметной

    области фамилия, имя и отчество могут рассматриваться как единое значение,

    а в другой – как три различных значения.

    Доменом называется множество атомарных значений одного и того же типа.

    Смысл доменов состоит в следующем. Если значения двух атрибутов берутся из

    одного и того же домена, то, вероятно, имеют смысл сравнения, использующие

    эти два атрибута (например, для организации транзитного рейса можно дать

    запрос "Выдать рейсы, в которых время вылета из Москвы в Сочи больше

    времени прибытия из Архангельска в Москву"). Если же значения двух

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

    смысла: стоит ли сравнивать номер рейса со стоимостью билета? Отношение на

    доменах D1, D2, ..., Dn (не обязательно, чтобы все они были различны)

    состоит из заголовка и тела. На рис. 3 приведен пример отношения для

    расписания движения самолетов.

    Заголовок состоит из такого фиксированного множества атрибутов A1, A2,

    ..., An, что существует взаимно однозначное соответствие между этими

    атрибутами Ai и определяющими их доменами Di (i=1,2,...,n).

    [pic]

    Рисунок 3. Отношение с математической точки зрения (Ai - атрибуты, Vi -

    значения атрибутов)

    Тело состоит из меняющегося во времени множества кортежей, где каждый

    кортеж состоит в свою очередь из множества пар атрибут-значение (Ai:Vi),

    (i=1,2,...,n), по одной такой паре для каждого атрибута Ai в заголовке. Для

    любой заданной пары атрибут-значение (Ai:Vi) Vi является значением из

    единственного домена Di, который связан с атрибутом Ai.

    Степень отношения – это число его атрибутов. Отношение степени один

    называют унарным, степени два – бинарным, степени три – тернарным, ..., а

    степени n – n-арным.

    Кардинальное число или мощность отношения – это число его кортежей.

    Кардинальное число отношения изменяется во времени в отличие от его

    степени.

    Поскольку отношение – это множество, а множества по определению не

    содержат совпадающих элементов, то никакие два кортежа отношения не могут

    быть дубликатами друг друга в любой произвольно-заданный момент времени.

    Пусть R – отношение с атрибутами A1, A2, ..., An. Говорят, что множество

    атрибутов K=(Ai, Aj, ..., Ak) отношения R является возможным ключом R тогда

    и только тогда, когда удовлетворяются два независимых от времени условия:

    1. Уникальность: в произвольный заданный момент времени никакие два

    различных кортежа R не имеют одного и того же значения для Ai, Aj,

    ..., Ak.

    2. Минимальность: ни один из атрибутов Ai, Aj, ..., Ak не может быть

    исключен из K без нарушения уникальности.

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

    меньшей мере комбинация всех его атрибутов удовлетворяет условию

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

    принимается за его первичный ключ. Остальные возможные ключи, если они

    есть, называются альтернативными ключами.

    Вышеупомянутые и некоторые другие математические понятия явились

    теоретической базой для создания реляционных СУБД, разработки

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

    высокую производительность, и создания основ теории проектирования баз

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

    использовать неформальные эквиваленты этих понятий:

    Отношение – Таблица (иногда Файл),

    Кортеж – Строка (иногда Запись),

    Атрибут – Столбец, Поле.

    3.2 Реляционная база данных

    Реляционная база данных – это совокупность отношений, содержащих всю

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

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

    1. Каждая таблица состоит из однотипных строк и имеет уникальное имя.

    2. Строки имеют фиксированное число полей (столбцов) и значений

    (множественные поля и повторяющиеся группы недопустимы). Иначе говоря, в

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

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

    значение или ничего.

    3. Строки таблицы обязательно воляет однозначно идентифицировать любую

    строку такой таблицы.

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

    размещаются однородные значения данных (даты, фамилии, целые числа или

    денежные суммы).

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

    значений данных и такой метод представления является единственным. В

    частности, не существует каких-либо специальных "связей" или указателей,

    соединяющих одну таблицу с другой. Так, связи между строкой с БЛ = 2

    таблицы "Блюда" на рис. 4 и строкой с ПР = 7 таблицы продукты (для

    приготовления Харчо нужен Рис), представляется не с помощью указателей, а

    благодаря существованию в таблице "Состав" строки, в которой номер блюда

    равен 2, а номер продукта – 7.

    6. При выполнении операций с таблицей ее строки и столбцы можно

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

    содержанию. Этому способствует наличие имен таблиц и их столбцов, а также

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

    признаками.

    |Блюда |Продукты |Состав |

    |БЛ |ПР |БЛ |

    |Блюдо |Продукт |ПР |

    |Вид |Калор. |Веc (г) |

    | | | |

    |1 |1 |1 |

    |Лобио |Фасоль |1 |

    |Закуска |3070 |200 |

    | | | |

    |2 |2 |1 |

    |Харчо |Лук |2 |

    |Суп |450 |40 |

    | | | |

    |3 |3 |1 |

    |Шашлык |Масло |3 |

    |Горячее |7420 |30 |

    | | | |

    |4 |4 |1 |

    |Кофе |Зелень |4 |

    |Десерт |180 |10 |

    | | | |

    | |5 |2 |

    |Расход |Мясо |5 |

    |БЛ |1660 |80 |

    |Порций | | |

    |Дата_Р |6 |2 |

    | |Томаты |2 |

    |1 |240 |30 |

    |158 | | |

    |1/9/94 |7 |2 |

    | |Рис |6 |

    |2 |3340 |40 |

    |144 | | |

    |1/9/94 |8 |2 |

    | |Кофе |7 |

    |3 |2750 |50 |

    |207 | | |

    |1/9/94 | |2 |

    | |Рецепты |3 |

    |4 |БЛ |15 |

    |235 |Рецепт | |

    |1/9/94 | |2 |

    | |1 |4 |

    |... |Ломаную очищ |15 |

    |... | | |

    |... |... |3 |

    | |... |5 |

    | | |180 |

    | | | |

    | | |3 |

    | | |6 |

    | | |100 |

    | | | |

    | | |3 |

    | | |2 |

    | | |40 |

    | | | |

    | | |3 |

    | | |4 |

    | | |20 |

    | | | |

    | | |4 |

    | | |8 |

    | | |8 |

    | | | |

    |Поставщики |Поставки |

    |ПОС |ПОС |

    |Поставщик |ПР |

    |Город |Вес (кг) |

    | |Цена |

    |1 |Дата_П |

    |"Полесье" | |

    |Киев |1 |

    | |6 |

    |2 |120 |

    |"Наталка" |0.45 |

    |Киев |27/8/94 |

    | | |

    |3 |1 |

    |"Хуанхэ" |3 |

    |Пекин |50 |

    | |1.82 |

    |4 |27/8/94 |

    |"Лайма" | |

    |Рига |1 |

    | |2 |

    |5 |50 |

    |"Юрмала" |0.61 |

    |Рига |27/8/94 |

    | | |

    |6 |2 |

    |"Даугава" |2 |

    |Рига |100 |

    | |0.52 |

    | |27/8/94 |

    |Города | |

    |Город |2 |

    |Страна |5 |

    | |100 |

    |Киев |2.18 |

    |Украина |27/8/94 |

    | | |

    |Пекин |2 |

    |Китай |4 |

    | |10 |

    |Рига |0.88 |

    |Латвия |27/8/94 |

    | | |

    | |3 |

    | |1 |

    | |250 |

    | |0.37 |

    | |24/8/94 |

    | | |

    | |3 |

    | |7 |

    | |75 |

    | |0.44 |

    | |24/8/94 |

    | | |

    | |3 |

    | |8 |

    | |40 |

    | |2.87 |

    | |24/8/94 |

    | | |

    | |4 |

    | |3 |

    | |70 |

    | |1.56 |

    | |30/8/94 |

    | | |

    | |5 |

    | |5 |

    | |200 |

    | |2.05 |

    | |30/8/94 |

    | | |

    | |6 |

    | |6 |

    | |15 |

    | |0.99 |

    | |30/8/94 |

    | | |

    Рисунок 4.База данных "Питание" .

    3.3 Манипулирование реляционными данными

    Стремление к минимизации числа таблиц для хранения данных может

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

    рекомендации по разбиению некоторых больших таблиц на несколько маленьких.

    Но как сформировать требуемый ответ, если нужные для него данные хранятся в

    разных таблицах?

    Предложив реляционную модель данных, Э.Ф.Кодд создал и инструмент для

    удобной работы с отношениями – реляционную алгебру. Каждая операция этой

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

    операндов и продуцирует в результате новую таблицу, т.е. позволяет

    "разрезать" или "склеивать" таблицы (рис. 5).

    [pic]

    Рисунок 5. Некоторые операции реляционной алгебры

    Созданы языки манипулирования данными, позволяющие реализовать все

    операции реляционной алгебры и практически любые их сочетания. Среди них

    наиболее распространены SQL (Structured Query Language – структуризованный

    язык запросов) и QBE (Quere-By-Example – запросы по образцу) . Оба

    относятся к языкам очень высокого уровня, с помощью которых пользователь

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

    получения.

    Заключение

    На сегодняшний день реляционные базы данных остаются самыми

    распространенными, благодаря своей простоте и наглядности как в процессе

    создания так и на пользовательском уровне.

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

    популярным языком запросов SQL. С помощью единственного запроса на этом

    языке можно соединить несколько таблиц во временную таблицу и вырезать из

    нее требуемые строки и столбцы (селекция и проекция). Так как табличная

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

    язык SQL является простым и легким для изучения. Реляционная модель имеет

    солидный теоретический фундамент, на котором были основаны эволюция и

    реализация реляционных баз данных. На волне популярности, вызванной успехом

    реляционной модели, SQL стал основным языком для реляционных баз данных.

    В процессе анализа вышеизложенной информации выявлены следующие

    недостатки рассмотренной модели баз данных:

    - так как все поля одной таблицы должны содержать постоянное число

    полей заранее определенных типов, приходится создавать

    дополнительные таблицы, учитывающие индивидуальные особенности

    элементов, при помощи внешних ключей. Такой подход сильно

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

    данных;

    - высокая трудоемкость манипулирования информацией и изменения

    связей.

    Литература

    1. Дейт К. Руководство по реляционной СУБД DB2. - М.: Финансы и

    статистика, 1988. - 320 с.

    2. Кириллов В.В. Основы проектирования реляционных баз данных .Учебное

    пособие. - СПб.: ИТМО, 1994. - 90 с.

    3. Мейер М. Теория реляционных баз данных. -М.: Мир, 1987. - 608 с.

    4. Ульман Дж. Базы данных на Паскале. -М.: Машиностроение, 1990. - 386 с.

    5. http://www.citforum.ru/database/sql_kg/index.shtml “ Основы

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

    Страницы: 1, 2


    Приглашения

    09.12.2013 - 16.12.2013

    Международный конкурс хореографического искусства в рамках Международного фестиваля искусств «РОЖДЕСТВЕНСКАЯ АНДОРРА»

    09.12.2013 - 16.12.2013

    Международный конкурс хорового искусства в АНДОРРЕ «РОЖДЕСТВЕНСКАЯ АНДОРРА»




    Copyright © 2012 г.
    При использовании материалов - ссылка на сайт обязательна.