Logo    
Деловая газета CitCity.ru CITKIT.ru - все об Open Source Форумы Все публикации Учебный центр Курилка
CitForum    CITForum на CD    Подписка на новости портала Море(!) аналитической информации! :: CITFORUM.RU
IT-консалтинг Software Engineering Программирование СУБД Безопасность Internet Сети Операционные системы Hardware

27.04.2017

Google
WWW CITForum.ru
С Новым годом!
2008 г.

Принципы организации иерархии атомарных литеральных типов объектной системы на основе РСУБД Microsoft SQL Server 2005

Олейник П.П., к.т.н.

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

Для снижения последствий ОРН широко используются методы (паттерны) объектно-реляционного отображения (ОРО, Object-Relational Mapping), суть применения которых заключается в возможности реализации элементов объектной системы (описания классов, создания иерархии наследования, описание отношений между классами и т.п.) на основе реляционной БД. Методы ОРО особое внимание уделяют проблеме сохранения экземпляров классов, значений атрибутов и т.п. С точки зрения реализации все методы ОРО можно разделить на две категории:

  1. Методы ОРО без поддержки метаинформации [1-3].

  2. Методы ОРО с поддержкой метаинформации [4].

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

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

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

Несмотря на наличие достаточно большого количества работ, посвящённых методам объектно-реляционного отображения, в каждой из них уделяется недостаточно внимания принципам организации атомарных литеральных типов в объектной системе. При этом существует несколько ортогональных подходов к решению описанной задачи. В работах, посвященных методам ОРО без поддержки метаинформации, атрибуты классов отображаются непосредственно на поля таблиц, в которых сохранены экземпляры классов [1-3]. При этом используются типы данных, присутствующие в СУБД. Так как данные методы предполагают выделение таблиц для сохранения объектов конкретной предметной области, то в них не предусмотрена унификация иерархии литеральных типов. В методах ОРО с поддержкой метаинформации, например, в «Сущность-Атрибут-Значение» (САЗ, Entity-Attribute-Value, EAV) выполняется выделение отдельных таблиц для представления конкретного типа данных [4]. При этом для каждого атрибута указывается имя таблицы, в которой будет физически сохраняться значение для конкретного объекта. Рассмотрим недостатки известных методов организации объектной системы в РБД и причины, не позволяющие успешно решать описанную задачу:

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

  2. Отсутствие единой спецификации. В отличие от объектных расширений языка SQL, базирующихся на стандарте SQL:2003 [5-6] и от объектных БД, для которых существует спецификация ODMG 3.0 [7-8], для объектно-реляционных отображений стандарта не существует.

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

Целью данной статьи является разработка унифицированной иерархии атомарных литеральных типов, применимой в любой объектной системе, построенной на основе реляционной базы данных. В полученной реализации должны отсутствовать недостатки, присущие имеющимся реализациям, и все выделенные типы не должны зависеть ни от типов, присутствующих в РСУБД, ни от метода ОРО, применённого при построении объектной системы. В заключении статьи представлена иерархия атомарных типов, построенная на основе типов данных, которые поддерживаются в РСУБД Microsoft SQL Server 2005.

Для проектирования оптимальной иерархии необходимо рассмотреть имеющиеся решения сходных задач, т.е. спецификацию как объектных расширений языка SQL (SQL:2003), так и объектно-ориентированных БД (ODMG 3.0).

Рассмотрим спецификацию ODMG 3.0. На рис. 1 изображён фрагмент метамодели ODMG 3.0, на котором описаны метаклассы, выделенные для представления атомарных литеральных типов [7-8].


Рис. 1. Фрагмент метамодели объектной системы стандарта ODMG 3.0

Рисунок требует пояснений. Для представления атомарных литеральных типов выделены класс d_Primitive_Type и перечисление d_TypeId. Причина выделения единственного класса в том, что в спецификации ODMG метамодель объектной системы логически отделена от атомарных типов (классов), имеющихся в системе (чисел, строк, коллекций, множеств и т.п.). С нашей точки зрения, такой подход имеет ряд недостатков. Присутствие одного класса предполагает наличие фиксированного набора атрибутов, т.е. каждый атомарный литеральный тип описывается определённым количеством параметров. Поэтому заранее необходимо выделить максимальное число атрибутов, часть из которых для определённых типов данных не будет иметь смысла. Для типа String, представляющего символьную строку, достаточно указать лишь длину (количество символов), а для типа Numeric, позволяющего сохранять дробные числа, потребуется указать уже два свойства: первое - для определения максимального количества символов в числе, а второе - для определения точности значения (количества символов после запятой). Для занесения информации об этих типах данных в классе d_Primitive_Type потребуется объявить оба свойства. При этом для типа String второе свойство избыточно и его значение не анализируется. В модели ODMG для определения встроенных атомарных литеральных типов выделено перечисление d_TypeId, которое содержит список зарезервированных констант. Этот список не может модифицироваться с целью отражения потребностей конкретного приложения. То есть недопустимо добавление новых литеральных типов. Тем не менее, имеется возможность создать псевдонимы типов, для представления которых выделен класс d_Alias_Type. Кроме того, в d_Primitive_Type отсутствует атрибут, предназначенный для сохранения информации о базовом классе примитивного типа. Т.е. атомарные литеральные типы в стандарте ODMG не организованы в иерархию.

Перейдём к рассмотрению языка SQL. На рис. 2 представлен фрагмент онтологии типов данных, реализующих объектные расширения языка SQL:2003 [9].


Рис. 2. Тип данных, используемый для представления атомарных литералов в SQL:2003

На рис. 2 видно, что для представления атомарных литеральных типов, которые в стандарте называются предопределёнными, выделен единственный класс Predefined. Т.е. стандарту SQL:2003 присущи недостатки, описанные в отношении представления литеральных типов в метамодели ODMG 3.0.

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

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

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

  3. Унификация всей иерархии базовых классов. Для данного требования сформулированы три подкритерия:

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

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

На рис. 3 представлена иерархия атомарных литеральных типов, удовлетворяющая сформулированым критериям. Рисунок требует пояснений. Все литеральные типы унаследованы от базового абстрактного класса AtomicLiteral. Этот класс в свою очередь может быть производным от корневого класса всей иерархии объектной системы. Тем самым реализован КО1, т.к. в единой иерархии присутствуют как классы метамодели объектной системы, так и классы доменов. Для каждой категории (числа, Number) и подкатегории (целые числа (IntegerNumber), дробные числа (FractionNumber)) типов данных введён абстрактный класс, от которого унаследованы реализованные классы (КО4).

Рис. 3. Иерархия литеральных типов объектной системы, отвечающая выделенным критериям

При сохранении (извлечении) экземпляра класса можно с помощью операции is проверить тип его класса и в соответствии с полученным результатом обработать его требуемым образом. Кроме того, для каждой категории типов, например, для целых чисел, выделен абстрактный базовый класс (IntegerNumber), от которого унаследованы конкретные реализации атомарных литеральных типов, входящих в группу (BigInt, Int, SmallInt, TinyInt, Bit). Такая реализация соответствует требованию КО4. Для введения дополнительного типа, позволяющего сохранять значения целых чисел, достаточно создать класс производный от IntegerNumber. Тем самым, реализован КО1, в котором требуется представление возможности определения производных классов от литеральных типов.

Как видно на рис. 3, каждый из присутствующих классов имеет только одного родителя, т.е. при проектировании иерархии использовано одиночное наследование, что позволило упростить реализацию и соответствует требованию КО2. В отличие от метамодели стандарта ODMG [7-8], активно применяющей множественное наследование (что связанно с использованием языка C++, в котором эта функциональность присутствует), в нашей реализации используется только одиночное наследование. Многие современные ООЯП (C#, Java) не поддерживают множественное наследование, поэтому представленная иерархия упрощает отображение присутствующих в ней классов на типы, имеющиеся в целевом языке. В случае необходимости для получения преимуществ, которые раньше достигались за счёт использования множественного наследования, можно применять интерфейсы.

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

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

Все присутствующие классы не привязаны к каким-либо конкретным типам данных, имеющимся в языке программирования (КО3). Поэтому при реализации конкретного приложения потребуется задать отображение (mapping) литеральных типов данных объектной системы на встроенные типы ООЯП. Подобный подход используется в стандарте ODMG, в котором определены отображения на языки С++, Java, SmallTalk [7-8]. При этом ИС проектируется в понятиях типов, присутствующих в объектной модели, а отображение выполняется при реализации клиентского приложения, что позволяет уменьшить зависимость отдельных звеньев системы друг от друга. Подведя итог, можно утверждать, что описанная иерархия литеральных типов соответствует выдвинутым критериям оптимальности.

Перейдём к вопросу о возможности практического применения разработанной иерархии в среде конкретной СУБД на примере Microsoft SQL Server 2005 [10]. Так как в соответствии с выделенными критериями оптимальности полученная иерархия атомарных литеральных типов (рис. 3) не зависит ни от конкретной предметной области, ни от целевой РСУБД (типов данных, которые в ней поддерживаются) и при этом позволяет определять производные классы, нам достаточно объявить дополнительные классы, которые однозначно соответствуют встроенному в СУБД типу данных. На рис. 4 изображена диаграмма классов иерархии литеральных типов для объектной системы, реализованной в среде СУБД Microsoft SQL Server 2005.

Рис. 4. Иерархия литеральных типов для СУБД Microsoft SQL Server 2005

Левая часть рисунка, на которой изображены классы, представляющие целые типы данных (производные от IntegerNumber) осталась неизменной потому, что данные типы присутствуют в Microsoft SQL Server 2005. Однако некоторые классы значений времени (классы, производные от Period) отсутствуют на рис. 4. Были исключены классы: Date, Time, Interval, т.к. подобных типов данных нет в целевой СУБД [10]. Отметим, что в версии Microsoft SQL Server 2008 появятся как типы данных, представляющие значения даты и времени (Date, Time, DateTime2, DateTimeOffset), так и тип, позволяющий организовать данные в иерархию (HierarchyId). В новой версии СУБД появятся типы, позволяющие сохранять географические (тип Geography) и геометрические (тип Geometry) координаты [11]. В последствии необходимо добавить эти типы данных к разработанной иерархии.

Ключевые изменения, представленные на рис. 4, коснулись корневых классов, соответствующих точным дробным числам (Numeric), приближенным дробным числам (Float), бинарным строкам как фиксированной длины (Binary), так и переменной длины (VarBinary), а также классов символьных строк, сохраняющих не только однобайтовые символы (Char, VarChar), но и позволяющих сохранять двубайтовые символы (NChar, NVarChar).

Все описанные выше классы сделаны абстрактными (см. рис.3 и рис.4) и, с нашей точки зрения, стали представлять собой категорию типов данных. Причина в том, что в выбранной СУБД для сохранения значений обозначенных типов данных необходимо указать максимальную длину в символах, а для дробных чисел требуется также указать и точность (количество символов после запятой) значения. Заданные параметры играют ключевую роль при расчёте занимаемого физического пространства, необходимого для значения [10]. Поэтому для класа Numeric выделены четыре абстрактных подкласса. Класс Numeric9_X предназначен для хранения чисел, имеющих длину 9 символов и занимающих в памяти 5 байтов; Numeric19_X позволяет сохранить числа, имеющие длину 19 символов и занимающих в памяти 9 байтов; Numeric28_X требует для сохранения значений 13 байтов, а Numeric38_X для этого потребуется уже 17 байтов. Для сохранения значений, имеющих определённую точность, выделены реализованные классы, производные от описанных четырёх абстрактных.

Тот же подход использован для классов, унаследованных от Float. Значения типа данных Float24 могут иметь длину до 7 знаков и занимают 4 байта, а значения типа Float53 – длину до 15 знаков и занимают 8 байтов.

В языке Transact-SQL имеется тип данных SQL_Variant, который в нашем случае является аналогом типа данных Variant, представленного на рис. 3.

Строки (как бинарные, так и символьные) требуют указания максимальной длины сохраняемого значение. На рис. 4 присутствуют реализованные классы, представляющие строки с заданной максимальной длиной. Следует учесть, что строки переменной длины (VarBinary, VarChar, NVarChar) в SQL Server могут иметь неограниченную длину; при спецификации соответствующего типа необходимо указать ключевое слово Max. Для подобных типов данных выделены соответствующие классы (VarBinaryMax, VarCharMax, NVarCharMax).

СУБД SQL Server 2005 имеет в своём составе типы данных Cursor и Table, которые не рассматриваются в данной статье потому, что они не являются атомарными литеральными.

Стоит отметить, что при проектировании приложения для конкретной предметной области при описании типов данных для атрибутов классов следует применять реализованные (не абстрактные) классы. Это связано с тем, что выделенная иерархия предполагает её использование при реализации объектной системы на основе РСУБД и в конечном счёте подразумевает сохранение значений атрибутов в полях таблиц БД. В случае использования абстрактных классов возникает неоднозначность при сохранении значений, что может привести к их урезанию и/или искажению.

В статье рассмотрена проблема организации иерархии атомарных литеральных типов объектной системы, построенной на основе РСУБД. Изучены имеющиеся реализации (метамодель стандарта ODMG 3.0, онтология SQL:2003), отмечены присущие недостатки и сформулированы критерии оптимальности, которым должна соответствовать спроектированная иерархия. На рис. 3 изображена оптимальная реализация, которая является унифицированной и не привязана ни к конкретному методу ОРО, ни к конкретной СУБД, а на рис. 4 представлена иерархия атомарных классов, организованных в соответствии с типами данных, имеющимися в СУБД Microsoft SQL Server 2005.

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

Благодарность

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

Литература

  1. Ambler S.W. Agile Database Techniques—Effective Strategies for the Agile Software, John Wiley & Sons, 2003, 373p.
  2. Keller W. Mapping Objects to Tables. A Pattern Language
  3. Флауер М. Архитектура корпоративных программных приложений, Пер. с англ. – М.: Издательский дом «Вильямс», 2004. – 544 с.: ил. – Парал. тит. англ.
  4. Nadkarni P. M., Brandt C. A., Morse R., Matthews K., Sun K., Deshpande A. M., Gadagkar R., Cohen D. B., Miller P. L. Metadata-driven creation of data marts from an EAV-modeled clinical research database // International Journal of Medical Informatics 65, 2002,p.225-241.
  5. Information technology — Database languages — SQL — Part 2: Foundation (SQL/Foundation)
  6. Кузнецов С. Наиболее интересные новшества в стандарте SQL:2003
  7. Cattell R.G., Barry D.K. The Object Data Standard:ODMG 3.0, Morgan Kaufmann Publishers, 2000, 288p.
  8. Джордан Д. Обработка объектных баз данных на C++. Программирование по стандарту ODMG. : Пер. с англ. : Уч. пос. - М.:Издательский дом "Вильямс", 2001.-384с.:ил.-Парал. тит. англ.
  9. Calero C., Ruiz F. and oth. An ontological approach to describe the SQL:2003 object-relational features, Ontologies for Software Engineering and Software Technology, Springer Berlin Heidelberg, 2006, 197-215pp.
  10. Sack J. SQL Server 2005 T-SQL Recipes: A Problem-Solution Approach, Apress, 2006, 769p.
  11. Wilson K. SQL Server 2008: Новые типы данных

1 Т.к. в русскоязычной литературе не сформировался устоявшийся перевод термина «Object-Relational Impedance Mismatch», то автором предложен собственный вариант, который (в отличие от имеющихся) явно указывает на наличие несоответствия между реляционной моделью данных и принципами объектно-ориентированной парадигмы.

Размещение рекламы — тел. +7 495 4119920, ICQ 232284597

Подписка на новости IT-портала CITForum.ru
(библиотека, CITKIT.ru, CitCity)

Новые публикации:

24 декабря

CITKIT.ru:

  • Новогодние поздравления
  • Сергей Кузнецов. Цикл Операционные системы: Ностальгия по будущему:

  • Алексей Федорчук. OpenSolaris 2008.11 Release

  • Сергей Голубев:

  • Евгений Чайкин aka StraNNik (Блогометки):

    17 декабря

  • С.Д.Кузнецов. Базы данных. Вводный курс

    10 декабря

    CITKIT.ru:

  • OpenSolaris 2008.11 Release

  • Альтернативные ОС: две грустные истории (С.Кузнецов)
  • Nokia N810 — доведение до ума
  • CitCity:

  • Платформа 2009: заоблачные перспективы Microsoft

    4 декабря

  • Лекция С.Д.Кузнецова Понятие модели данных. Обзор разновидностей моделей данных

    CITKIT.ru:

  • OpenSolaris 2008.11 Release. Первые впечатления

  • Linux vs FreeBSD: продолжим "Священные войны"?

  • Nokia N810 as is

  • Индульгенция для FOSS

  • Друзья СПО'2008

    26 ноября

  • Нечеткое сравнение коллекций: семантический и алгоритмический аспекты

    CitCity:

    CITKIT.ru:

  • Глава из книги А.Федорчука
    Сага о FreeBSD:
  • 19 ноября

  • Проблемы экономики производства крупных программных продуктов

  • Язык модификации данных формата XML функциональными методами

    CITKIT.ru:

  • Главы из книги А.Федорчука
    Сага о FreeBSD:

    Заметки к книге:

  • FreeBSD: монтирование сменных устройств и механизм HAL
  • Текстовый редактор ee

    12 ноября

  • Правило пяти минут двадцать лет спустя, и как флэш-память изменяет правила (Гоц Грейф, перевод: Сергей Кузнецов)

    CITKIT.ru:

  • Главы из книги А.Федорчука
    Сага о FreeBSD:
  • OSS в России: взгляд правоведа (В.Житомирский)

  • Новая статья из цикла С.Голубева "Железный марш":

    29 октября

  • О некоторых задачах обратной инженерии

  • Веб-сервисы и Ruby

  • Тестирование web-приложений с помощью Ruby

    CITKIT.ru:

  • Главы из книги А.Федорчука
    Сага о FreeBSD:

  • PuppyRus Linux - беседа с разработчиком (С.Голубев)

  • Сергей Кузнецов. Заметка не про Linux

    22 октября

  • Обзор методов описания встраиваемой аппаратуры и построения инструментария кросс-разработки

    CITKIT.ru:

  • Сергей Кузнецов. Почему я равнодушен к Linux

  • Глава из книги А.Федорчука
    Сага о FreeBSD:
  • Что надо иметь
    3. Базовые познания

    CitCity:

  • Управление IT-инфраструктурой на основе продуктов Microsoft

    15 октября

  • Методы бикластеризации для анализа интернет-данных

    CitCity:

  • Разъемы на ноутбуках: что они дают и зачем их так много?
  • AMD Puma и Intel Centrino 2: кто лучше?

    CITKIT.ru:

  • Новый цикл статей С.Голубева
    Железный марш:

  • Главы из книги А.Федорчука
    Сага о FreeBSD:

    8 октября

  • Автоматизация тестирования web-приложений, основанных на скриптовых языках
  • Опыт применения технологии Azov для тестирования библиотеки Qt3

    Обзоры журнала Computer:

  • SOA с гарантией качества
  • Пикоджоуль ватт бережет
  • ICT и всемирное развитие

    CitCity:

  • Пиррова победа корпорации Microsoft

    CITKIT.ru:

  • Главы из книги А.Федорчука
    Сага о FreeBSD:

    Статья из архива:

  • Я живу в FreeBSD (Вадим Колонцов)

    Новые Блогометки:

  • Перекройка шаблона Blogger или N шагов к настоящему
  • Blogger. Comment style
  • Screenie или глянцевый снимок экрана

    2 октября

    CITKIT.ru:

  • Сага о FreeBSD (А. Федорчук)

    Zenwalk: пакет недели

  • Банинг — интеллектуальное развлечение (С.Голубев)

    CitCity:

    25 сентября

  • Клермонтский отчет об исследованиях в области баз данных

    CITKIT.ru:

  • Пользователям просьба не беспокоиться... (В.Попов)

  • Снова про ZFS: диск хорошо, а два лучше
  • Командная оболочка tcsh (А.Федорчук)

    Zenwalk: пакет недели

    17 сентября

  • T2C: технология автоматизированной разработки тестов базовой функциональности программных интерфейсов
  • Технология Azov автоматизации массового создания тестов работоспособности

    CITKIT.ru:

  • FreeBSD: ZFS vs UFS, и обе-две — против всех (А.Федорчук)

    Zenwalk: пакет недели

  • Дачнет — практика без теории (С.Голубев)

    10 сентября

  • За чем следить и чем управлять при работе приложений с Oracle
  • Планировщик заданий в Oracle
    (В.Пржиялковский)

    CITKIT.ru:

  • Microsoft: ответный "боян" (С.Голубев)

  • Причуды симбиоза, или снова "сделай сам" (В.Попов)

  • Файловые системы современного Linux'а: последнее тестирование
  • Zsh. Введение и обзор возможностей
    (А.Федорчук)

    Описания пакетов Zenwalk: Zsh, Thunar, Thunar-bulk-rename, Xfce4-places-plugin, Xfce4-fsguard-plugin

    Блогометки:

  • Google Chrome
  • Лончер для ASUS Eee PC 701

    3 сентября

    CITKIT.ru:

  • Заметки о ядре (А.Федорчук):

    Добавлены описания пакетов Zenwalk: Galculator, Screenshot, Gnumeric, Pidgin

    В дискуссинном клубе:

  • И еще о Википедии и Google Knol

  • Лекция для начинающего линуксоида (С.Голубев)

    26 августа

  • Транзакционная память (Пересказ: С. Кузнецов)

    CITKIT.ru:

  • Открыт новый проект Zenwalk: пакет недели

  • Статья Текстовые процессоры и их быстродействие: конец еще одной легенды?

    21 августа

    CITKIT.ru:

  • Почему школам следует использовать только свободные программы (Ричард Столлман)
  • Беседа Сергея Голубева с учителем В.В.Михайловым

  • Википедия или Гуглезнание? Приглашение к обсуждению (Алексей Федорчук)
  • Народная энциклопедия от Google (StraNNik)

  • Обзор Mandriva 2009.0 Beta 1 Thornicrofti
  • Новичок в Линукс: Оптимизируем Mandriva 2008.1

  • Книга Zenwalk. Приобщение к Linux:

    13 августа

    CitCity:

  • Мирный Atom на службе человеку. Обзор платы Intel D945GCLF с интегрированным процессором
  • Обзор процессоров Intel Atom 230 на ядре Diamondville

  • iPhone - год спустя. Скоро и в России?

    CITKIT.ru:

  • Интермедия 3.4. GRUB: установка и настройка (из книги Zenwalk. Приобщение к Linux)

    6 августа

  • СУБД с хранением данных по столбцами и по строкам: насколько они отличаются в действительности? (Пересказ: С. Кузнецов)

    CITKIT.ru:

  • Интермедия 2.2. Что неплохо знать для начала (из книги Zenwalk. Приобщение к Linux)

  • И снова про шрифты в Иксах (А.Федорчук)

  • 20 самых быстрых и простых оконных менеджеров для Linux

  • Дело о трех миллиардах (С.Голубев)

    30 июля

  • OLTP в Зазеркалье (Пересказ: С. Кузнецов)

    CitCity:

  • Будущее BI в облаках?
  • Тиражные приложения и заказная разработка. Преимущества для заказчика
  • Дискуссия со сторонниками заказной разработки

    CITKIT.ru:

  • Новые главы книги Zenwalk. Приобщение к Linux:
  • Глава 8. Пакеты: средства установки, системы управления, системы построения
  • Глава 9. Zenwalk: репозитории, пакеты, методы установки

    23 июля

    CITKIT.ru:

  • Все против всех. 64 vs 32, Intel vs AMD, tmpfs vs ext3
  • Две головы от Intel

  • Zenwalk: обзор штатных приложений (глава из книги "Zenwalk. Приобщение к Linux")

  • Нормально, Григорий...

    16 июля

    Обзоры журнала Computer:

  • Перспективы и проблемы программной инженерии в XXI веке
  • Большие хлопоты с большими объемами данных
  • Перспективы наноэлектроники

    CITKIT.ru:

  • Интермедия о лицензиях (А.Федорчук. "Zenwalk. Приобщение к Linux")

  • Есть ли будущее у KDE?

  • Linux в школе: альтернативный вариант в задачах

  • Шифр (приключения агента Никодима)

    10 июля

    CITKIT.ru:

  • Новые разделы книги А. Федорчука Zenwalk. Приобщение к Linux:
  • Интермедия вступительная. Linux или GNU/Linux? Как вас теперь называть?
  • Глава 5. Среда Xfce
  • Глава 6. Xfce: приложения и плагины

  • ZUR (Zenwalk User Repository) FAQ

    2 июля

  • Персистентность данных в объектно-ориентированных приложениях (С. Кузнецов)

    CITKIT.ru:

  • Новые разделы книги А. Федорчука Zenwalk. Приобщение к Linux:
  • Интермедия 1.2. Дорога к Zenwalk'у. Период бури и натиска
  • Интермедия 3.3. Немного о Linux'е и "железе"
  • Глава 4. Настройка: инструментами и руками
  • Интермедия 4.1. Zenpanel и конфиги: поиски корреляции

  • Интервью с Жан-Филиппом Гийоменом, создателем дистрибутива Zenwalk

  • Linux в школе: первые итоги (С. Голубев)

    25 июня

    CITKIT.ru:

  • Zenwalk. Приобщение к Linux (А. Федорчук)

  • Логика и риторика (С.Голубев)

  • Технология Tru64 AdvFS

  • Ханс Райзер предлагает отвести полицейских к телу Нины

    18 июня

  • Проекты по управлению данными в Google (Пересказ: С. Кузнецов)

    CITKIT.ru:

  • ОС и поддержка "железа": мифы и реальность (А. Федорчук)

  • Linux в школе: другие дистрибутивы

  • Пинок (С. Голубев)

    4 июня

  • Ландшафт области управления данными: аналитический обзор (С. Кузнецов)

    CITKIT.ru:

  • Linux в школе: слово заинтересованным лицам

  • SlackBuild: пакеты своими руками

  • Linux от компании Novell. Установка и обзор openSUSE Linux

    Все публикации >>>




  • IT-консалтинг Software Engineering Программирование СУБД Безопасность Internet Сети Операционные системы Hardware

    Информация для рекламодателей PR-акции, размещение рекламы — тел. +7 495 4119920, ICQ 232284597 Пресс-релизы — pr@citcity.ru
    Послать комментарий
    Информация для авторов
    Rambler's Top100 TopList liveinternet.ru: показано число просмотров за 24 часа, посетителей за 24 часа и за сегодня This Web server launched on February 24, 1997
    Copyright © 1997-2000 CIT, © 2001-2007 CIT Forum
    Внимание! Любой из материалов, опубликованных на этом сервере, не может быть воспроизведен в какой бы то ни было форме и какими бы то ни было средствами без письменного разрешения владельцев авторских прав. Подробнее...