Реквизиты базы данных что это

Это прислал hc.ru для www.ksoftware.ru

——- ниже то, что прислал хостер ———

Здравствуйте!

Информация для доступа к базе данных MySQL wwwksoftwareru_phpBB

Хост: db.ksoftwar.mass.hc.ru
Логин: ksoftwar_phpBB
Пароль: ********

Подробнее об использовании базы данных MySQL можно узнать раздела «Помощь» (http://help.hc.ru/)

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

—
С уважением, Хостинг-Центр РБК

Офис в Москве
тел.: +7 (495) 544-55-66
e-mail: hosting@hc.ru

Офис в Санкт-Петербурге
тел.: +7 (812) 448-30-04
e-mail: hosting@spb.hc.ru

Hello!

Information for access to MySQL database wwwksoftwareru_phpBB

Host: db.ksoftwar.mass.hc.ru
Login: ksoftwar_phpBB
Password: ********

More detailed information about the use of MySQL database you can find in section «Help» (http://help.hc.ru/)

Please contact our Support Service if any further information is required:

—
Best Regards, Hosting-Center RBC

Moscow office
tel.: +7 (495) 544-55-66
e-mail: hosting@hc.ru

St.-Petersburg office
tel.: +7 (812) 448-30-04
e-mail: hosting@spb.hc.ru

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

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

Понятие и место атрибута

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

• Атрибуты данных являются минимальной единицей их структуры. При описании БД каждому ее элементу дается отдельное имя, по которому его вызывают в ходе обработки базы данных (элемент иногда именуется полем).
• Записями называют комплекс атрибутов с наименованием. Благодаря им можно в ходе одного обращения к БД получить связанный комплекс данных. С записями выполняются операции добавления, удаления и изменения. Их тип устанавливается набором атрибутов. В свою очередь экземпляр записи – конкретная строка с определенными значениями элементов.
• Групповое отношение – иерархическое расположение строк двух типов. Родительская или исходная запись выступает «владельцем» такой иерархии, а дочерняя выступает по отношению к ней подчиненной. В древовидной БД записи может сохраняться лишь две иерархические структуры.

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

В графическом виде иерархическое расположение записей осуществляется с помощью дуг ориентированного графа. Типы строк отображаются записей – вершинами диаграммы Бахмана.

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

Примеры атрибутов

Приведем пример, в котором минимальная единица структуры БД получила атрибуты: Name, Code, Subcategory, StandardCost, ListPrice и FilePhoto. Атрибуты выступают описанием полей БД. При этом любой отдельный элемент представляется отдельной записью значений атрибута.

В примере объект БД Product включает:

• атрибуты в свободном виде Name, Code, StandardCost и ListPrice;
• атрибут с учетом подмножества Subcategory;
• метаданные описания файла FilePhoto.

Скачать файл

Объект Subcategory применяется как минимальная единица записи на основании подмножества сущности Product. В свою очередь объект Category применяется как минимальная единица записи на основании подмножества сущности Subcategory. Аналогично с объектом Product, сущности Category и Subcategory безусловно включают атрибуты Name и Code.

Виды атрибутов

Строковые поля

Чтобы рассмотреть атрибуты базы данных составим табличный документ

При БД все объекты получают свой набор свойств, присущих определенному типу. Так, объект типа «EMPLOYEE» включает следующие свойства строк:

«FAMILY» — фамилия

«FIRSTNAME» — имя

«LASTNAME» — отчество

«ADDRESS» — адрес

«EMAIL» — e-mail

Строку Objects.ItemName для работников заполняет сервер программы в виде комбинация атрибутов FAMILY + FIRSTNAME + LASTNAME.

Хранение атрибутов осуществляется в табличной форме:

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

SELECT O.ItemName, S.Value

FROM Objects O

INNER JOIN ObjType OT ON O.TypeId = OT.Id

INNER JOIN Strings S ON O.Id = S.ObjectId

INNER JOIN StrDesc SD ON S.TypeId = SD.Id

WHERE OT.Code = ‘EMPLOYEE’

AND SD.TypeId = OT.Id

AND SD.Code = ‘EMAIL’

Чтобы вывести список работников с данными e-mail (если такие присутствуют), необходимо изменить запрос:

SELECT O.ItemName, S.Value

FROM Objects O

INNER JOIN ObjType OT ON O.TypeId = OT.Id

LEFT JOIN Strings S ON O.Id = S.ObjectId

LEFT JOIN StrDesc SD ON S.TypeId = SD.Id

WHERE OT.Code = ‘EMPLOYEE’

AND SD.TypeId = OT.Id

AND SD.Code = ‘EMAIL’

При создании для разных типов объектов атрибутов с идентичными данными в поле Code можно получить довольно любопытный результат. Допустим, объекты EMPLOYEE (работник) и FIRM (компания) имеют одинаковые атрибуты строк: ‘EMAIL’. В этом случае по одному запросу можно вывести список адресов по всем доступным в базе данных почтовым реквизитам.

SELECT O.ItemName, OT.ItemName, S.Value

FROM Objects O

INNER JOIN ObjType OT ON O.TypeId = OT.Id

INNER JOIN Strings S ON O.Id = S.ObjectId

INNER JOIN StrDesc SD ON S.TypeId = SD.Id

WHERE SD.Code = ‘EMAIL’

ORDER BY OT.ItemName, O.ItemName

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

Числовые атрибуты

Чтобы упростить ситуацию предположим, что хранение всех числовых атрибутов организовано с использованием одного типа данных (к примеру, DECIMAL(20,4). Такой подход удобен при использовании серверов типа MONE.

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

А сами атрибуты — в таблице:

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

Хронологические атрибуты

В определенных временных отрезках состояние объектов БД может меняться. К примеру, работник может приниматься на испытательный срок, увольняться, переводиться и т.д. Описание состояний отображается в табличной форме:

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

• «WASBORN» — Дата рождения
• «EMPLOYEED» — Принят на должность
• «DISMISS» — Уволен

В этом случае можно обеспечить принцип, при котором каждое состояние объекта будет появляться неоднократно. К примеру, работник принят на должность, уволен и снова принят.

Хронология изменений сохраняется в табличной форме:

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

SELECT O.ItemName, H.ItemDate AS Employeed

FROM Objects O

INNER JOIN ObjType OT ON O.TypeId = OT.Id

INNER JOIN History H ON H.ObjectId = O.Id

INNER JOIN Status S ON H.StatusId = S.Id

WHERE OT.Code = ‘EMPLOYEE’

AND S.Code = ‘EMPLOYEED’

AND H.ItemDate = (SELECT MAX(H1.ItemDate)

FROM History H1

INNER JOIN Status S1 ON H1.StatusId = S1.Id

WHERE H1.ObjectId = O.Id

AND H.ItemDate <= :DateParam

AND S1.Code IN (‘EMPLOYEED’, ‘DISMISS’))

Атрибуты с ограниченным числом значений

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

Вторая — определяет возможные значения для перечислимого типа:

Третья — непосредственно хранит значения, связанные с объектом:

Иллюстративным примером применения данных такого типа выступает форма собственности компании. Чтобы выяснить этот вопрос, необходимо включить строку в EnumDesc:

И в EnumValues:

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

Методы исполнения атрибутов

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

Вызов способа (метода) исполнения внешним воздействием на состояние данных. Различают 4 таких метода: Create, Set, Get и Update.

Первый метод из этого списка соответствует мета-классу и применяется для любого объекта класса. Его параметром выступает описатель IDC целевого класса. С помощью способа Create объекты создаются, как сопутствующие атрибутам указанного класса элементы. При этом класс регистрируется в табличной форме аллокации DAT за вслед за свободным описателем IDO.

Методы Set, Get и Update относятся мета-атрибутам. Они используются для работы со значениями объектов данных. Метод атрибута Set присваивает значения, Get обеспечивает его выборку, а Update инициирует переформирование производного значения, которое хранится в БД.

Идентификация целевого значения в методах атрибута обеспечивается описателем IDO. При этом, сам целевой объект доступен только для атрибута класса (путь к этому атрибуту указан в описателях IDC+IDA модели данных).

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

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

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

Структура реляционных баз данных

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

Структура таблицы

В реляционных базах данных информация хранится в связанных друг с другом таблицах.
Сами же таблицы состоят из:

• строк, которые называют «записи»
• столбцов, которые называют «полями» или же «атрибутами»

В каждой таблице каждый столбец имеет заранее определённый тип данных. Например, такими типами могу выступать:

• VARCHAR (строковый тип данных)
• INTEGER (числовой тип данных)
• DATETIME (тип данных для даты и времени) и прочие

И каждая строка таблицы должна иметь соответствующий тип для каждого столбца. СУБД не допустит попытку добавления
в поле с типом DATETIME произвольной строки.

Для того, чтобы узнать типы данных атрибутов можно выполнить SQL команду DESCRIBE и указать название таблицы:

Или же посмотреть на ERD-диаграмму схемы базы данных:

Первичный ключ

Любая СУБД имеет встроенную систему целостности и непротиворечивости данных.
Эта система работает на наборе правил, определённых в схеме базы данных. Первичный ключ и внешние ключи как раз
являются одними из таких правил.

Чтобы избегать неоднозначности при поиске в таблицах присутствуют первичный ключ или, как его ещё называют,
«ключевое поле».

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

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

Внешний ключ

Внешний ключ – это поле (или набор полей) в одной таблице, которое ссылается на первичный ключ в другой таблице.

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

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

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

Если внешний ключ не определён, то всё также будет работать, но СУБД
не будет проверять, что, например, при создании записи в таблице Purchase в полях buyer_id и good_id лежат
значения, которые определены в соответствующих таблицах в поле id.

Какое из утверждений неверное относительно ключей в реляционных СУБД ?